claudeos-core 1.2.3 → 1.3.0

package/pass-prompts/templates/node-express/pass3.md

@@ -4,11 +4,30 @@ generate all ClaudeOS-Core files based on the analysis results.
 
 Do not read the original source code again. Reference only the analysis results.
 
+CRITICAL — Package Manager Consistency:
+Check `stack.packageManager` in project-analysis.json (e.g., "pnpm", "yarn", "npm").
+ALL generated files MUST use ONLY that detected package manager's commands.
+For example, if packageManager is "pnpm": use `pnpm run build`, `pnpm run dev`, `pnpm install`, etc.
+NEVER mix npm/yarn/pnpm commands. Also check `scripts` field in the project's package.json
+for actual script names (e.g., "eslint" not "lint", "typecheck" not "tsc --noEmit").
+
+CRITICAL — Cross-file Consistency:
+Rules (.claude/rules/) and Standards (claudeos-core/standard/) MUST NOT contradict each other.
+If a standard defines a specific pattern (e.g., import path, file naming, API usage),
+the corresponding rule MUST use the same pattern. Before generating each rule file,
+verify it is consistent with the related standard file.
+
+CRITICAL — CLAUDE.md Reference Table Completeness:
+The reference table in CLAUDE.md MUST list ALL generated standard files, not just core.
+Include all frontend-ui, backend-api, security-db, infra, and verification standards.
+Alternatively, add a note directing readers to .claude/rules/00.core/00.standard-reference.md
+for the complete list.
+
 Generation targets:
 
 1. CLAUDE.md (project root)
    - Role definition (based on detected stack)
-   - Build & Run Commands (npm/yarn/pnpm)
+   - Build & Run Commands (use ONLY the detected packageManager — never hardcode npm/yarn/pnpm)
    - Core architecture diagram
    - DB table/collection naming
    - Standard/Skills/Guide reference table

package/pass-prompts/templates/node-nextjs/pass1.md

@@ -19,9 +19,13 @@ Analysis items (per domain):
    - Component structure (functional, forwardRef, memo)
    - Props type definition (interface vs type, Generic usage)
    - State management (useState, useReducer, external libraries)
-   - Styling (CSS Modules, Tailwind, styled-components, Emotion)
-   - UI library (shadcn/ui, MUI, Ant Design, Radix)
+   - Styling approach and exact import paths (e.g., `import styles from './index.module.scss'`, `import { cn } from '@/lib/utils'`)
+   - Styling utility functions: record the EXACT import path used in source code (e.g., `from '@lfos-poc-ui/utils'` NOT `from '@app/shared/lib/classNames'`)
+   - UI library and exact package names (e.g., `@lfos-poc-ui/ui`, `@shadcn/ui`, `@mui/material`)
    - Component classification (UI, Feature, Layout, Page)
+   - Component entry file pattern: is the main file `index.tsx` or `ComponentName.tsx`? Record exactly which pattern the project uses.
+   - Directory structure pattern: record exact convention (e.g., `ComponentName/index.tsx` vs `ComponentName/ComponentName.tsx`)
+   - export pattern: default export vs named export in component files
    - Reuse patterns (composition, compound components, render props)
    - Accessibility (ARIA, semantic HTML, keyboard navigation)
 
@@ -97,7 +101,13 @@ Save results to claudeos-core/generated/pass1-{{PASS_NUM}}.json in the following
       },
       "patterns": {
         "page": { ... },
-        "component": { ... },
+        "component": {
+          "entryFilePattern": "index.tsx or ComponentName.tsx",
+          "exportPattern": "default export or named export",
+          "stylingImport": "exact import statement used for styling utility",
+          "uiLibraryImport": "exact import statement for UI components",
+          ...
+        },
         "dataFetching": { ... },
         "stateManagement": { ... },
         "config": { ... },

package/pass-prompts/templates/node-nextjs/pass2.md

@@ -27,14 +27,16 @@ Merge items:
 
 5. Naming Conventions Summary
    - File/directory naming (kebab-case, PascalCase)
-   - Component naming conventions
+   - Component entry file pattern (index.tsx vs ComponentName.tsx — pick ONE that the project actually uses)
+   - Component export pattern (default export vs named export)
    - Hook naming (use* prefix)
    - API route patterns
 
 6. Shared Types/Components List
-   - Common UI components
-   - Shared hooks
-   - Utility functions
+   - Common UI components with EXACT import paths (e.g., `from '@lfos-poc-ui/ui'`, NOT invented paths)
+   - Shared hooks with exact import paths
+   - Utility functions with EXACT import paths (e.g., `from '@lfos-poc-ui/utils'` for classNamesWithRoot)
+   - Path aliases used in the project (e.g., `@app/` → `src/`, `@/` → `src/`)
    - Environment variable types
    - Constants/Enum management
 

package/pass-prompts/templates/node-nextjs/pass3.md

@@ -4,11 +4,30 @@ generate all ClaudeOS-Core files based on the analysis results.
 
 Do not read the original source code again. Reference only the analysis results.
 
+CRITICAL — Package Manager Consistency:
+Check `stack.packageManager` in project-analysis.json (e.g., "pnpm", "yarn", "npm").
+ALL generated files MUST use ONLY that detected package manager's commands.
+For example, if packageManager is "pnpm": use `pnpm run build`, `pnpm run dev`, `pnpm install`, etc.
+NEVER mix npm/yarn/pnpm commands. Also check `scripts` field in the project's package.json
+for actual script names (e.g., "eslint" not "lint", "typecheck" not "tsc --noEmit").
+
+CRITICAL — Cross-file Consistency:
+Rules (.claude/rules/) and Standards (claudeos-core/standard/) MUST NOT contradict each other.
+If a standard defines a specific pattern (e.g., import path, file naming, API usage),
+the corresponding rule MUST use the same pattern. Before generating each rule file,
+verify it is consistent with the related standard file.
+
+CRITICAL — CLAUDE.md Reference Table Completeness:
+The reference table in CLAUDE.md MUST list ALL generated standard files, not just core.
+Include all frontend-ui, backend-api, security-db, infra, and verification standards.
+Alternatively, add a note directing readers to .claude/rules/00.core/00.standard-reference.md
+for the complete list.
+
 Generation targets:
 
 1. CLAUDE.md (project root)
    - Role definition (based on detected stack)
-   - Build & Run Commands (npm/yarn/pnpm, dev/build/start)
+   - Build & Run Commands (use ONLY the detected packageManager — never hardcode npm/yarn/pnpm)
    - Core architecture diagram
    - Directory structure description
    - Standard/Skills/Guide reference table

package/pass-prompts/templates/python-django/pass1.md

@@ -11,6 +11,7 @@ Analysis items (per domain):
    - URL configuration (urlpatterns, Router registration, namespace)
    - Parameter handling (request.data, serializer, query_params, kwargs)
    - Response format (Response, JsonResponse, TemplateResponse)
+   - If a custom response wrapper/mixin exists, record its EXACT class name, EXACT method signatures, and EXACT import path. Do NOT guess — read the actual source.
    - Error handling (exception_handler, DRF exceptions, custom exceptions)
    - Authentication (permission_classes, authentication_classes)
    - API documentation (drf-spectacular, drf-yasg, @extend_schema)
@@ -38,8 +39,9 @@ Analysis items (per domain):
    - Architecture (Fat Model vs Service Layer vs Domain Service)
    - Transactions (transaction.atomic, select_for_update, savepoint)
    - Celery tasks (shared_task, retry, priority)
-   - Utility/helper functions
+   - Utility/helper functions with EXACT import paths (e.g., `from apps.common.utils import format_date`)
    - Event handling (django-signals, custom event bus)
+   - Import paths: record EXACT import conventions used in the project (relative vs absolute, app prefix)
 
 5. Configuration/Environment Patterns
    - Settings separation (base/local/staging/production)

package/pass-prompts/templates/python-django/pass2.md

@@ -34,10 +34,10 @@ Merge items:
    - Test file structure
 
 6. Common Models/Utilities List
-   - Abstract model fields
-   - Shared Manager/QuerySet
-   - Utility functions
-   - Constants/Enum management
+   - Abstract model fields with EXACT import paths (e.g., `from apps.common.models import BaseModel`)
+   - Shared Manager/QuerySet with EXACT module locations
+   - Utility functions with EXACT import paths
+   - Constants/Enum management with EXACT locations
 
 7. Security/Authentication Patterns
    - Authentication method (JWT, Session, Token, OAuth2)

package/pass-prompts/templates/python-django/pass3.md

@@ -4,6 +4,24 @@ generate all ClaudeOS-Core files based on the analysis results.
 
 Do not read the original source code again. Reference only the analysis results.
 
+CRITICAL — Package Manager Consistency:
+Check `stack.packageManager` in project-analysis.json (e.g., "poetry", "pipenv", "pip").
+ALL generated files MUST use ONLY that detected package manager's commands.
+For example, if packageManager is "poetry": use `poetry run`, `poetry add`, etc.
+NEVER mix pip/poetry/pipenv commands. Also check actual script names in pyproject.toml or Makefile.
+
+CRITICAL — Cross-file Consistency:
+Rules (.claude/rules/) and Standards (claudeos-core/standard/) MUST NOT contradict each other.
+If a standard defines a specific pattern (e.g., import path, file naming, API usage),
+the corresponding rule MUST use the same pattern. Before generating each rule file,
+verify it is consistent with the related standard file.
+
+CRITICAL — CLAUDE.md Reference Table Completeness:
+The reference table in CLAUDE.md MUST list ALL generated standard files, not just core.
+Include all backend-api, security-db, infra, and verification standards.
+Alternatively, add a note directing readers to .claude/rules/00.core/00.standard-reference.md
+for the complete list.
+
 Generation targets:
 
 1. CLAUDE.md (project root)

package/pass-prompts/templates/python-fastapi/pass1.md

@@ -11,6 +11,7 @@ Analysis items (per domain):
    - Path decorators (@router.get, @router.post, @router.put, @router.delete)
    - Parameter handling (Path, Query, Body, Header, Cookie, Depends)
    - Response model (response_model, status_code, response_class)
+   - If a custom response wrapper/schema exists, record its EXACT class name, EXACT method signatures, and EXACT import path. Do NOT guess — read the actual source.
    - Error handling (HTTPException, exception_handler, custom exceptions)
    - Authentication (Depends-based JWT/OAuth2, Security schemes)
    - API documentation (auto OpenAPI, tags, summary, description, deprecated)
@@ -40,6 +41,8 @@ Analysis items (per domain):
    - Dependency hierarchy (nested Depends)
    - Custom dependency functions/classes
    - Lifecycle events (lifespan, startup/shutdown)
+   - Import paths: record EXACT import conventions (e.g., `from app.core.deps import get_db`, not invented paths)
+   - Utility function locations: record EXACT module paths for shared utilities
    - Dependency overrides (for testing)
 
 5. Configuration/Environment Patterns

package/pass-prompts/templates/python-fastapi/pass2.md

@@ -33,10 +33,10 @@ Merge items:
    - File structure conventions
 
 6. Common Models/Utilities List
-   - Base model fields
-   - Shared dependency functions
-   - Utility functions
-   - Constants/Enum management
+   - Base model fields with EXACT import paths (e.g., `from app.core.base import BaseModel`)
+   - Shared dependency functions with EXACT module paths
+   - Utility functions with EXACT import paths
+   - Constants/Enum management with EXACT locations
 
 7. Security/Authentication Patterns
    - Authentication method (JWT Bearer, OAuth2PasswordBearer)

package/pass-prompts/templates/python-fastapi/pass3.md

@@ -4,6 +4,24 @@ generate all ClaudeOS-Core files based on the analysis results.
 
 Do not read the original source code again. Reference only the analysis results.
 
+CRITICAL — Package Manager Consistency:
+Check `stack.packageManager` in project-analysis.json (e.g., "poetry", "pipenv", "pip").
+ALL generated files MUST use ONLY that detected package manager's commands.
+For example, if packageManager is "poetry": use `poetry run`, `poetry add`, etc.
+NEVER mix pip/poetry/pipenv commands. Also check actual script names in pyproject.toml or Makefile.
+
+CRITICAL — Cross-file Consistency:
+Rules (.claude/rules/) and Standards (claudeos-core/standard/) MUST NOT contradict each other.
+If a standard defines a specific pattern (e.g., import path, file naming, API usage),
+the corresponding rule MUST use the same pattern. Before generating each rule file,
+verify it is consistent with the related standard file.
+
+CRITICAL — CLAUDE.md Reference Table Completeness:
+The reference table in CLAUDE.md MUST list ALL generated standard files, not just core.
+Include all backend-api, security-db, infra, and verification standards.
+Alternatively, add a note directing readers to .claude/rules/00.core/00.standard-reference.md
+for the complete list.
+
 Generation targets:
 
 1. CLAUDE.md (project root)

package/plan-installer/domain-grouper.js

@@ -0,0 +1,74 @@
+/**
+ * ClaudeOS-Core — Domain Grouper
+ *
+ * Splits domains into analysis groups, determines active domains,
+ * and selects appropriate templates based on detected stack.
+ */
+
+function splitDomainGroups(domains, type, template) {
+  const MAX_FILES_PER_GROUP = 40;
+  const MAX_DOMAINS_PER_GROUP = 4;
+  const groups = [];
+  let current = [];
+  let fileCount = 0;
+
+  for (const d of domains) {
+    // Flush current group before adding if it would exceed limits
+    if (current.length > 0 && (fileCount + d.totalFiles >= MAX_FILES_PER_GROUP || current.length >= MAX_DOMAINS_PER_GROUP)) {
+      groups.push({ type, template, domains: [...current], estimatedFiles: fileCount });
+      current = [];
+      fileCount = 0;
+    }
+    current.push(d.name);
+    fileCount += d.totalFiles;
+  }
+  if (current.length > 0) {
+    groups.push({ type, template, domains: [...current], estimatedFiles: fileCount });
+  }
+
+  return groups;
+}
+
+// ─── Determine active domains ───────────────────────────────────
+function determineActiveDomains(stack) {
+  const isBackend = !!stack.framework;
+  return {
+    "00.core": true,
+    "10.backend": !!isBackend,
+    "20.frontend": !!stack.frontend,
+    "30.security-db": !!(stack.database || stack.framework),
+    "40.infra": true,
+    "50.verification": true,
+    "90.optional": true,
+  };
+}
+
+// ─── Template selection (multi-stack) ──────────────────────────────
+function selectTemplates(stack) {
+  const templates = { backend: null, frontend: null };
+
+  // Backend template
+  if (stack.language === "kotlin") templates.backend = "kotlin-spring";
+  else if (stack.language === "java") templates.backend = "java-spring";
+  else if (stack.framework === "express" || stack.framework === "nestjs") templates.backend = "node-express";
+  else if (stack.framework === "django") templates.backend = "python-django";
+  else if (stack.framework === "fastapi" || stack.framework === "flask") templates.backend = "python-fastapi";
+  else if (stack.language === "typescript" || stack.language === "javascript") templates.backend = "node-express";
+  else if (stack.language === "python") templates.backend = "python-fastapi";
+
+  // Frontend template
+  if (stack.frontend === "nextjs" || stack.frontend === "react" || stack.frontend === "vue") {
+    templates.frontend = "node-nextjs";
+  }
+
+  // Pure frontend project with no backend
+  if (!templates.backend && templates.frontend) {
+    templates.backend = null;
+  }
+
+  return templates;
+}
+
+// ─── Dynamic prompt generation (multi-stack) ──────────────────────
+
+module.exports = { splitDomainGroups, determineActiveDomains, selectTemplates };