claudeos-core 2.4.1 → 2.4.3

package/README.hi.md

@@ -7,58 +7,40 @@
 [![license](https://img.shields.io/npm/l/claudeos-core.svg?color=blue)](LICENSE)
 [![downloads](https://img.shields.io/npm/dm/claudeos-core.svg?logo=npm&color=blue&label=downloads)](https://www.npmjs.com/package/claudeos-core)
 
-**Claude Code को पहली कोशिश में ही _आपके प्रोजेक्ट की_ परिपाटियों का पालन करवाएँ — generic defaults का नहीं।**
-
-एक deterministic Node.js scanner पहले आपके कोड को पढ़ता है; फिर एक 4-pass Claude पाइपलाइन पूरा सेट लिखती है — `CLAUDE.md` + auto-loaded `.claude/rules/` + standards + skills + L4 memory. 10 output भाषाएँ, 5 post-generation validators, और एक स्पष्ट path allowlist जो LLM को आपके कोड में मौजूद न होने वाली फ़ाइलें या frameworks आविष्कार करने से रोकता है।
-
-[**12 stacks**](#supported-stacks) पर काम करता है (monorepos सहित) — एक `npx` command, कोई config नहीं, resume-safe, idempotent.
+**एक ऐसा CLI tool जो आपके actual source code को पढ़कर `CLAUDE.md` और `.claude/rules/` खुद generate कर देता है। Node.js scanner, 4-pass Claude pipeline और 5 validators मिलकर काम करते हैं। 12 stacks और 10 भाषाएँ support हैं, और जो path code में नहीं है वो output में भी नहीं आएगा।**
 
 ```bash
 npx claudeos-core init
 ```
 
+[**12 stacks**](#supported-stacks) पर सीधे चलता है (monorepos भी)। एक command, कोई config नहीं, बीच में रुक जाए तो वहीं से resume होता है, और बार-बार चलाने पर भी safe है।
+
 [🇺🇸 English](README.md) · [🇰🇷 한국어](README.ko.md) · [🇨🇳 中文](README.zh-CN.md) · [🇯🇵 日本語](README.ja.md) · [🇪🇸 Español](README.es.md) · [🇻🇳 Tiếng Việt](README.vi.md) · [🇷🇺 Русский](README.ru.md) · [🇫🇷 Français](README.fr.md) · [🇩🇪 Deutsch](README.de.md)
 
 ---
 
 ## यह क्या है?
 
-आप Claude Code का उपयोग करते हैं। यह शक्तिशाली है, लेकिन हर session नए सिरे से शुरू होता है — इसे _आपके_ प्रोजेक्ट की संरचना की कोई स्मृति नहीं होती। इसलिए यह "generally good" defaults पर fallback करता है जो आपकी टीम वास्तव में जो करती है उससे शायद ही मेल खाते हैं:
-
-- आपकी टीम **MyBatis** का उपयोग करती है, लेकिन Claude JPA repositories उत्पन्न करता है।
-- आपका response wrapper `ApiResponse.ok()` है, लेकिन Claude `ResponseEntity.success()` लिखता है।
-- आपके packages layer-first (`controller/order/`) हैं, लेकिन Claude domain-first (`order/controller/`) बनाता है।
-- आपकी errors centralized middleware से जाती हैं, लेकिन Claude हर endpoint में `try/catch` बिखेर देता है।
+Claude Code हर नए session पर framework के generic defaults पर वापस चला जाता है। आपकी team **MyBatis** use करती है, फिर भी Claude JPA का code लिख देता है। आपका response wrapper `ApiResponse.ok()` है, फिर भी Claude `ResponseEntity.success()` लिखता है। Packages आपने layer-first design किए हैं, मगर Claude domain-first structure बना देता है। हर repo के लिए `.claude/rules/` खुद से लिखकर रखना इसका एक हल है, लेकिन जैसे ही code evolve होता है आपके rules drift करने लगते हैं।
 
-आप चाहेंगे कि प्रति प्रोजेक्ट एक `.claude/rules/` set हो — Claude Code इसे हर session में स्वतः लोड करता है — लेकिन हर नए repo के लिए हाथ से वे rules लिखने में घंटों लगते हैं, और कोड के विकसित होने के साथ वे drift हो जाते हैं।
+**ClaudeOS-Core यही काम deterministically करता है, सीधे आपके actual source code से।** पहले एक Node.js scanner project को पढ़ता है, यानी stack, ORM, package layout और file paths सब निकाल लेता है। उसके बाद 4-pass Claude pipeline पूरा set generate करती है। `CLAUDE.md`, auto-load होने वाले `.claude/rules/`, standards, skills — ये सब एक explicit path allowlist के अंदर ही बनते हैं, और LLM इस दायरे से बाहर नहीं जा सकता। आखिर में 5 validators output को ship होने से पहले verify कर लेते हैं।
 
-**ClaudeOS-Core उन्हें आपके वास्तविक स्रोत कोड से आपके लिए लिखता है।** एक deterministic Node.js scanner पहले आपके प्रोजेक्ट को पढ़ता है (stack, ORM, package layout, परिपाटियाँ, फ़ाइल paths). फिर एक 4-pass Claude पाइपलाइन निकाले गए तथ्यों को एक संपूर्ण documentation set में बदलती है:
+नतीजा यह है कि same input के लिए हमेशा byte-identical output मिलता है, चाहे 10 भाषाओं में से कोई भी चुनी जाए, और कभी invented path नहीं आएगा। (विस्तार से नीचे [क्या इसे अलग बनाता है](#क्या-इसे-अलग-बनाता-है) में।)
 
-- **`CLAUDE.md`** — वह project index जिसे Claude हर session में पढ़ता है
-- **`.claude/rules/`** — श्रेणी के अनुसार auto-loaded rules (`00.core` / `10.backend` / `20.frontend` / `30.security-db` / `40.infra` / `60.memory` / `70.domains` / `80.verification`)
-- **`claudeos-core/standard/`** — reference docs (हर rule के पीछे का "क्यों")
-- **`claudeos-core/skills/`** — पुनः-प्रयोग योग्य patterns (CRUD scaffolding, page templates)
-- **`claudeos-core/memory/`** — decision log + failure patterns जो प्रोजेक्ट के साथ बढ़ते हैं
-
-क्योंकि scanner Claude को एक स्पष्ट path allowlist देता है, LLM **आपके कोड में मौजूद न होने वाली फ़ाइलें या frameworks आविष्कार नहीं कर सकता**। पाँच post-generation validators (`claude-md-validator`, `content-validator`, `pass-json-validator`, `plan-validator`, `sync-checker`) ship से पहले output को सत्यापित करते हैं — language-invariant, इसलिए वही rules लागू होते हैं चाहे आप English, Korean, या अन्य 8 भाषाओं में से किसी में भी उत्पन्न करें।
-
-```
-पहले:  आप → Claude Code → "generally good" कोड → हर बार मैन्युअल फ़िक्सिंग
-बाद में:  आप → Claude Code → आपके प्रोजेक्ट से मेल खाता कोड → सीधे ship
-```
+लंबे चलने वाले projects के लिए एक अलग [Memory Layer](#memory-layer-वैकल्पिक-दीर्घकालिक-प्रोजेक्ट्स-के-लिए) भी seed होता है।
 
 ---
 
-## एक वास्तविक प्रोजेक्ट पर देखें
+## वास्तविक प्रोजेक्ट पर देखें
 
-[`spring-boot-realworld-example-app`](https://github.com/gothinkster/spring-boot-realworld-example-app) पर चलाएँ — Java 11 · Spring Boot 2.6 · MyBatis · SQLite · 187 source files. आउटपुट: **75 generated files**, कुल समय **53 minutes**, सभी validators ✅।
+[`spring-boot-realworld-example-app`](https://github.com/gothinkster/spring-boot-realworld-example-app) पर इसे चलाकर देखा गया। Java 11, Spring Boot 2.6, MyBatis, SQLite, कुल 187 source files. Output: **75 generated files**, total time **53 मिनट**, और सभी validators ✅।
 
 <p align="center">
   <img src="docs/assets/spring-boot-realworld-demo.gif" alt="ClaudeOS-Core init running on spring-boot-realworld-example-app — stack detection, 4-pass pipeline, validators, completion summary" width="769">
 </p>
 
 <details>
-<summary><strong>📺 टर्मिनल आउटपुट (टेक्स्ट संस्करण, खोज और कॉपी के लिए)</strong></summary>
+<summary><strong>Terminal output (text version, search और copy के लिए)</strong></summary>
 
 ```text
 ╔════════════════════════════════════════════════════╗
@@ -93,18 +75,18 @@ npx claudeos-core init
     [██████████░░░░░░░░░░] 50% (2/4)
 
 [6] Pass 3 — Generating all files...
-    🚀 Pass 3 split mode (3a → 3b → 3c → 3d-aux)
+    Pass 3 split mode (3a → 3b → 3c → 3d-aux)
     ✅ 3a complete (2m 57s)            — pass3a-facts.md (187-path allowlist)
     ✅ 3b complete (18m 49s)           — CLAUDE.md + 19 standards + 20 rules
     ✅ 3c complete (12m 35s)           — 13 skills + 9 guides
     ✅ 3d-aux complete (3m 18s)        — database/ + mcp-guide/
-    🎉 Pass 3 split complete: 4/4 stages successful
+    Pass 3 split complete: 4/4 stages successful
     [███████████████░░░░░] 75% (3/4)
 
 [7] Pass 4 — Memory scaffolding...
-    📦 Pass 4 staged-rules: 6 rule files moved to .claude/rules/
+    Pass 4 staged-rules: 6 rule files moved to .claude/rules/
     ✅ Pass 4 complete (5m)
-       📋 Gap-fill: all 12 expected files already present
+       Gap-fill: all 12 expected files already present
     [████████████████████] 100% (4/4)
 
 ╔═══════════════════════════════════════╗
@@ -133,7 +115,7 @@ npx claudeos-core init
 </details>
 
 <details>
-<summary><strong>📄 आपकी <code>CLAUDE.md</code> में क्या जाता है (वास्तविक अंश — Section 1 + 2)</strong></summary>
+<summary><strong>असली <code>CLAUDE.md</code> में आखिर क्या लिखा जाता है (वास्तविक excerpt — Section 1 + 2)</strong></summary>
 
 ```markdown
 # CLAUDE.md — spring-boot-realworld-example-app
@@ -142,7 +124,7 @@ npx claudeos-core init
 > Java 11 + Spring Boot 2.6, exposing both REST and GraphQL endpoints
 > over a hexagonal MyBatis persistence layer.
 
-## 1. Role Definition
+#### 1. Role Definition
 
 As the senior developer for this repository, you are responsible for
 writing, modifying, and reviewing code. Responses must be written in English.
@@ -150,7 +132,7 @@ A Java Spring Boot REST + GraphQL API server organized around a hexagonal
 (ports & adapters) architecture, with a CQRS-lite read/write split inside
 an XML-driven MyBatis persistence layer and JWT-based authentication.
 
-## 2. Project Overview
+#### 2. Project Overview
 
 | Item | Value |
 |---|---|
@@ -166,12 +148,12 @@ an XML-driven MyBatis persistence layer and JWT-based authentication.
 | Test Stack | JUnit Jupiter 5, Mockito, AssertJ, rest-assured, spring-mock-mvc |
 ```
 
-ऊपर के सभी मान — सटीक dependency coordinates, `dev.db` filename, `V1__create_tables.sql` migration name, "no JPA" — Claude द्वारा फ़ाइल लिखने से पहले scanner द्वारा `build.gradle` / `application.properties` / source tree से निकाले जाते हैं। कुछ भी अनुमानित नहीं है।
+ऊपर table में जो भी value है — exact dependency coordinates, `dev.db` filename, `V1__create_tables.sql` migration नाम, "no JPA" तक — वो सब Claude के file लिखने से पहले scanner ने `build.gradle`, `application.properties` और source tree से सीधे निकाला है। एक भी value guess नहीं की गई।
 
 </details>
 
 <details>
-<summary><strong>🛡️ एक वास्तविक auto-loaded rule (<code>.claude/rules/10.backend/01.controller-rules.md</code>)</strong></summary>
+<summary><strong>एक असली auto-loaded rule (<code>.claude/rules/10.backend/01.controller-rules.md</code>)</strong></summary>
 
 ````markdown
 ---
@@ -179,9 +161,9 @@ paths:
   - "**/*"
 ---
 
-# Controller Rules
+#### Controller Rules
 
-## REST (`io.spring.api.*`)
+##### REST (`io.spring.api.*`)
 
 - Controllers are the SOLE response wrapper for HTTP — no aggregator/facade above them.
   Return `ResponseEntity<?>` or a body Spring serializes via `JacksonCustomizations`.
@@ -194,13 +176,13 @@ paths:
 - Let exceptions propagate to `io.spring.api.exception.CustomizeExceptionHandler`
   (`@ControllerAdvice`). Do NOT `try/catch` business exceptions inside the controller.
 
-## GraphQL (`io.spring.graphql.*`)
+##### GraphQL (`io.spring.graphql.*`)
 
 - DGS components (`@DgsComponent`) are the sole GraphQL response wrappers.
   Use `@DgsQuery` / `@DgsData` / `@DgsMutation`.
 - Resolve the current user via `io.spring.graphql.SecurityUtil.getCurrentUser()`.
 
-## Examples
+##### Examples
 
 ✅ Correct:
 ```java
@@ -228,15 +210,15 @@ public ResponseEntity<?> create(@RequestBody NewArticleParam p) {
 ```
 ````
 
-`paths: ["**/*"]` glob का अर्थ है कि जब भी आप प्रोजेक्ट की किसी भी फ़ाइल को संपादित करते हैं, Claude Code इस rule को स्वचालित रूप से लोड करता है। rule में हर class name, package path, और exception handler सीधे स्कैन किए गए स्रोत से आता है — प्रोजेक्ट के वास्तविक `CustomizeExceptionHandler` और `JacksonCustomizations` सहित।
+`paths: ["**/*"]` glob का मतलब है कि project में जब भी कोई file edit हो, Claude Code इस rule को अपने आप load कर लेता है। Rule में जितने भी class names, package paths और exception handlers हैं, वो सब scanned source से सीधे आए हैं। यानी project का असली `CustomizeExceptionHandler` और `JacksonCustomizations` जैसा है, वैसा ही यहाँ झलकता है।
 
 </details>
 
 <details>
-<summary><strong>🧠 एक स्वतः उत्पन्न <code>decision-log.md</code> seed (वास्तविक अंश)</strong></summary>
+<summary><strong>Auto-generated <code>decision-log.md</code> seed (वास्तविक excerpt)</strong></summary>
 
 ```markdown
-## 2026-04-26 — Hexagonal ports & adapters with MyBatis-only persistence
+#### 2026-04-26 — Hexagonal ports & adapters with MyBatis-only persistence
 
 - **Context:** `io.spring.core.*` exposes `*Repository` ports (e.g.,
   `io.spring.core.article.ArticleRepository`) implemented by
@@ -255,260 +237,276 @@ public ResponseEntity<?> create(@RequestBody NewArticleParam p) {
   split the persistence model.
 ```
 
-Pass 4 `pass2-merged.json` से निकाले गए architectural निर्णयों के साथ `decision-log.md` को seed करता है ताकि भविष्य के sessions याद रखें कि codebase जैसा है _वैसा क्यों है_ — सिर्फ़ यह नहीं कि _कैसा दिखता है_। हर option ("JPA/Hibernate", "MyBatis-Plus") और हर consequence वास्तविक `build.gradle` dependency block पर आधारित है।
+Pass 4 `pass2-merged.json` से निकले architectural decisions को `decision-log.md` में पहले से भर देता है। इसका फायदा यह है कि अगले sessions में codebase जैसा दिख रहा है उसका *क्या* ही नहीं, *क्यों* भी याद रहता है। हर option ("JPA/Hibernate", "MyBatis-Plus") और हर consequence असली `build.gradle` dependency block पर ही टिका हुआ है।
 
 </details>
 
 ---
 
-## Quick Start
+## परीक्षण किया गया
 
-**पूर्वापेक्षाएँ:** Node.js 18+, [Claude Code](https://docs.anthropic.com/en/docs/claude-code) इंस्टॉल और प्रमाणित।
+ClaudeOS-Core असली OSS projects पर लिए गए reference benchmarks के साथ ship होता है। अगर आपने इसे किसी public repo पर चलाया है, तो [issue खोल दीजिए](https://github.com/claudeos-core/claudeos-core/issues), हम इसे table में जोड़ देंगे।
+
+| Project | Stack | Scanned → Generated | Status |
+|---|---|---|---|
+| [`spring-boot-realworld-example-app`](https://github.com/gothinkster/spring-boot-realworld-example-app) | Java 11 · Spring Boot 2.6 · MyBatis · SQLite | 187 → 75 files | ✅ सभी 5 validators pass |
+
+---
+
+## त्वरित शुरुआत
+
+**Prerequisites:** Node.js 18+, और [Claude Code](https://docs.anthropic.com/en/docs/claude-code) installed व authenticated।
 
 ```bash
-# 1. अपने प्रोजेक्ट रूट पर जाएँ
+# 1. अपने project root पर जाएँ
 cd my-spring-boot-project
 
-# 2. init चलाएँ (यह आपके कोड का विश्लेषण करता है और Claude से rules लिखने को कहता है)
+# 2. init चलाएँ (यह code analyze करता है और Claude से rules लिखवाता है)
 npx claudeos-core init
 
-# 3. हो गया। Claude Code खोलें और कोडिंग शुरू करें — आपके rules पहले से लोड हैं।
+# 3. हो गया। Claude Code खोलिए और काम शुरू कीजिए — rules पहले से loaded हैं।
 ```
 
-`init` समाप्त होने के बाद **आपको क्या मिलता है**:
+`init` खत्म होने के बाद structure कुछ ऐसा दिखेगा।
 
 ```
 your-project/
 ├── .claude/
-│   └── rules/                    ← Claude Code द्वारा स्वतः लोड
+│   └── rules/                    ← Claude Code इन्हें auto-load करता है
 │       ├── 00.core/              (सामान्य rules — naming, architecture)
-│       ├── 10.backend/           (backend stack rules, यदि लागू हो)
-│       ├── 20.frontend/          (frontend stack rules, यदि लागू हो)
-│       ├── 30.security-db/       (security & DB परिपाटियाँ)
+│       ├── 10.backend/           (backend stack rules, अगर हैं तो)
+│       ├── 20.frontend/          (frontend stack rules, अगर हैं तो)
+│       ├── 30.security-db/       (security और DB conventions)
 │       ├── 40.infra/             (env, logging, CI/CD)
-│       ├── 50.sync/              (doc-sync रिमाइंडर — rules only)
-│       ├── 60.memory/            (memory rules — Pass 4, rules only)
+│       ├── 50.sync/              (doc-sync reminders — सिर्फ rules में)
+│       ├── 60.memory/            (memory rules — Pass 4, सिर्फ rules में)
 │       ├── 70.domains/{type}/    (per-domain rules, type = backend|frontend)
-│       └── 80.verification/      (testing strategy + build verification रिमाइंडर)
+│       └── 80.verification/      (testing strategy और build verification reminders)
 ├── claudeos-core/
-│   ├── standard/                 ← Reference docs (श्रेणी संरचना का दर्पण)
+│   ├── standard/                 ← Reference docs (वही category structure)
 │   │   ├── 00.core/              (project overview, architecture, naming)
-│   │   ├── 10.backend/           (backend reference — backend stack पर)
-│   │   ├── 20.frontend/          (frontend reference — frontend stack पर)
-│   │   ├── 30.security-db/       (security & DB reference)
+│   │   ├── 10.backend/           (backend reference — backend stack हो तो)
+│   │   ├── 20.frontend/          (frontend reference — frontend stack हो तो)
+│   │   ├── 30.security-db/       (security और DB reference)
 │   │   ├── 40.infra/             (env / logging / CI-CD reference)
 │   │   ├── 70.domains/{type}/    (per-domain reference)
-│   │   ├── 80.verification/      (build / startup / testing reference — standard only)
-│   │   └── 90.optional/          (stack-specific extras — standard only)
-│   ├── skills/                   (Claude द्वारा लागू किए जा सकने वाले पुनः-प्रयोग योग्य पैटर्न)
-│   ├── guide/                    (सामान्य कार्यों के लिए how-to गाइड)
-│   ├── database/                 (schema overview, migration गाइड)
-│   ├── mcp-guide/                (MCP integration नोट्स)
+│   │   ├── 80.verification/      (build / startup / testing reference — सिर्फ standard में)
+│   │   └── 90.optional/          (stack-specific extras — सिर्फ standard में)
+│   ├── skills/                   (reusable patterns जिन्हें Claude apply कर सकता है)
+│   ├── guide/                    (आम tasks के how-to guides)
+│   ├── database/                 (schema overview, migration guide)
+│   ├── mcp-guide/                (MCP integration notes)
 │   └── memory/                   (decision log, failure patterns, compaction)
-└── CLAUDE.md                     (वह index जिसे Claude सबसे पहले पढ़ता है)
+└── CLAUDE.md                     (Claude सबसे पहले इसी index को पढ़ता है)
 ```
 
-`rules/` और `standard/` के बीच एक ही संख्या prefix साझा करने वाली श्रेणियाँ एक ही वैचारिक क्षेत्र को दर्शाती हैं (उदाहरण: `10.backend` rules ↔ `10.backend` standards)। केवल-rules श्रेणियाँ: `50.sync` (doc sync रिमाइंडर) और `60.memory` (Pass 4 memory)। केवल-standard श्रेणी: `90.optional` (बिना enforcement के stack-specific extras)। अन्य सभी prefix (`00`, `10`, `20`, `30`, `40`, `70`, `80`) `rules/` और `standard/` दोनों में दिखाई देते हैं। अब Claude Code आपका प्रोजेक्ट जानता है।
+जिन categories का number prefix `rules/` और `standard/` दोनों में same है, वो एक ही area की हैं (जैसे `10.backend` rules ↔ `10.backend` standards)। सिर्फ rules में रहने वाली categories हैं `50.sync` (doc sync reminders) और `60.memory` (Pass 4 memory)। सिर्फ standard में रहने वाली एक है `90.optional` (बिना enforcement के stack-specific extras)। बाकी सारे prefixes (`00`, `10`, `20`, `30`, `40`, `70`, `80`) दोनों जगह मौजूद हैं। अब Claude Code आपके project को जानता है।
 
 ---
 
 ## यह किसके लिए है?
 
-| आप हैं... | यह pain जो हटाता है |
+| आप कौन हैं... | यह जो pain हटाता है |
 |---|---|
-| **Claude Code के साथ नया प्रोजेक्ट शुरू करने वाले एकल डेवलपर** | "हर session Claude को मेरी परिपाटियाँ सिखाना" — खत्म। `CLAUDE.md` + 8-श्रेणी `.claude/rules/` एक pass में उत्पन्न। |
-| **multiple repos में साझा standards बनाए रखने वाले team lead** | जब लोग packages का नाम बदलते हैं, ORMs बदलते हैं, या response wrappers बदलते हैं तो `.claude/rules/` drift हो जाते हैं। ClaudeOS-Core deterministically पुनः-sync करता है — समान input, byte-identical output, कोई diff noise नहीं। |
-| **Claude Code पहले से उपयोग कर रहे लेकिन उत्पन्न कोड को ठीक करते-करते थके हुए** | गलत response wrapper, गलत package layout, MyBatis का उपयोग होने पर JPA, centralized middleware होने पर बिखरे हुए `try/catch`। Scanner आपकी वास्तविक परिपाटियाँ निकालता है; प्रत्येक Claude pass एक स्पष्ट path allowlist पर चलता है। |
-| **एक नए repo में onboarding** (मौजूदा प्रोजेक्ट, टीम में शामिल होना) | repo पर `init` चलाएँ, एक जीवित architecture map मिलेगा: CLAUDE.md में stack table, ✅/❌ उदाहरणों के साथ per-layer rules, प्रमुख विकल्पों के "क्यों" के साथ seeded decision log (JPA vs MyBatis, REST vs GraphQL, आदि)। 5 फ़ाइलें पढ़ना 5,000 source फ़ाइलें पढ़ने को हराता है। |
-| **Korean / Japanese / Chinese / 7 अन्य भाषाओं में काम करना** | अधिकांश Claude Code rule generators केवल English हैं। ClaudeOS-Core **10 भाषाओं** (`en/ko/ja/zh-CN/es/vi/hi/ru/fr/de`) में पूरा सेट लिखता है **byte-identical संरचनात्मक validation** के साथ — output भाषा से स्वतंत्र वही `claude-md-validator` verdict। |
-| **monorepo पर चलाना** (Turborepo, pnpm/yarn workspaces, Lerna) | Backend + frontend domains एक run में अलग-अलग prompts के साथ analyzed; `apps/*/` और `packages/*/` स्वतः walked; प्रति-stack rules `70.domains/{type}/` के तहत emit होते हैं। |
-| **OSS में योगदान या प्रयोग** | Output gitignore-friendly है — `claudeos-core/` आपकी local working dir है, केवल `CLAUDE.md` + `.claude/` ship करना ज़रूरी है। बाधित होने पर resume-safe; पुनः चलाने पर idempotent (`--force` के बिना rules में आपके मैन्युअल edits सुरक्षित रहते हैं)। |
+| **Solo dev जो Claude Code से नया project शुरू कर रहा है** | "हर session में Claude को conventions फिर से सिखाओ" — यह झंझट खत्म। `CLAUDE.md` और 8-category `.claude/rules/` एक ही pass में बन जाते हैं। |
+| **Team lead जो कई repos में shared standards maintain करता है** | जब लोग packages rename करते हैं, ORMs बदलते हैं, या response wrappers switch करते हैं, तब `.claude/rules/` drift करने लगते हैं। ClaudeOS-Core इन्हें deterministically फिर से sync कर देता है। Same input = byte-identical output, कोई diff noise नहीं। |
+| **पहले से Claude Code use कर रहे हैं लेकिन generated code ठीक करते-करते थक चुके हैं** | गलत response wrapper, गलत package layout, MyBatis project में JPA code, centralized middleware के बावजूद बिखरा हुआ `try/catch` — यह सब scanner आपके असली conventions निकालकर रोकता है, और हर Claude pass एक explicit path allowlist पर ही चलता है। |
+| **नए repo पर onboarding कर रहे हैं** (existing project, team join कर रहे हैं) | Repo पर `init` चलाइए, एक living architecture map मिल जाता है — CLAUDE.md में stack table, ✅/❌ examples के साथ per-layer rules, और बड़े decisions के पीछे "why" से seed किया हुआ decision log (JPA vs MyBatis, REST vs GraphQL, वगैरह)। 5 files पढ़ना 5,000 source files पढ़ने से कहीं तेज़ है। |
+| **हिन्दी / कोरियाई / जापानी / चीनी समेत 7 अन्य भाषाओं में काम कर रहे हैं** | अधिकांश Claude Code rule generators सिर्फ English में लिखते हैं। ClaudeOS-Core पूरा set **10 भाषाओं** (`en/ko/ja/zh-CN/es/vi/hi/ru/fr/de`) में लिखता है, और structural validation **byte-identical** रहता है — output language कोई भी हो, `claude-md-validator` का verdict same रहता है। |
+| **Monorepo पर काम कर रहे हैं** (Turborepo, pnpm/yarn workspaces, Lerna) | एक ही run में backend और frontend domains अलग-अलग prompts से analyze होते हैं। `apps/*/` और `packages/*/` खुद-ब-खुद walk हो जाते हैं, और per-stack rules `70.domains/{type}/` के नीचे emit होते हैं। |
+| **OSS में contribute कर रहे हैं या experiment कर रहे हैं** | Output gitignore-friendly है। `claudeos-core/` आपकी local working dir है, और ship सिर्फ `CLAUDE.md` + `.claude/` को करना है। बीच में रुक जाए तो resume-safe, और re-runs पर idempotent — आपके manual edits बिना `--force` के बच जाते हैं। |
 
-**यदि उपयुक्त नहीं:** यदि आप scan चरण के बिना दिन एक से काम करने वाला agents/skills/rules का one-size-fits-all preset bundle चाहते हैं ([docs/hi/comparison.md](docs/hi/comparison.md) देखें कि क्या कहाँ फिट होता है), आपका प्रोजेक्ट अभी [समर्थित stacks](#supported-stacks) में से किसी से मेल नहीं खाता, या आपको केवल एक एकल `CLAUDE.md` चाहिए (बिल्ट-इन `claude /init` पर्याप्त है — अन्य tool इंस्टॉल करने की आवश्यकता नहीं)।
+**यह आपके लिए सही नहीं है अगर:** आपको एक one-size-fits-all preset bundle चाहिए जो scan step के बिना day one से काम करे (कौन सा tool कहाँ fit होता है, यह [docs/hi/comparison.md](docs/hi/comparison.md) में है), या आपका project अभी [supported stacks](#supported-stacks) में से किसी में नहीं आता, या फिर आपको सिर्फ एक `CLAUDE.md` चाहिए। उस case में built-in `claude /init` ही काफी है, अलग tool install करने की जरूरत नहीं।
 
 ---
 
 ## यह कैसे काम करता है?
 
-ClaudeOS-Core सामान्य Claude Code workflow को उलट देता है:
+ClaudeOS-Core typical Claude Code workflow को उल्टा करके चलाता है।
 
 ```
-सामान्य:    आप प्रोजेक्ट का वर्णन करते हैं → Claude आपके stack का अनुमान लगाता है → Claude docs लिखता है
-यह:         कोड आपके stack को पढ़ता है → कोड पुष्ट तथ्य Claude को देता है → Claude तथ्यों से docs लिखता है
+सामान्य: आप project describe करते हैं → Claude आपके stack का अंदाज़ा लगाता है → Claude docs लिखता है
+यह:     Code आपके stack को पढ़ता है → Code confirmed facts Claude को देता है → Claude उन्हीं facts से docs लिखता है
 ```
 
-पाइपलाइन **तीन चरणों** में चलती है, LLM call के दोनों ओर कोड के साथ:
+Pipeline **तीन stages** में चलती है, और LLM call के दोनों तरफ code रहता है।
 
-**1. Step A — Scanner (deterministic, कोई LLM नहीं)।** एक Node.js scanner आपके project root को walk करता है, `package.json` / `build.gradle` / `pom.xml` / `pyproject.toml` पढ़ता है, `.env*` फ़ाइलों को parse करता है (`PASSWORD/SECRET/TOKEN/JWT_SECRET/...` के लिए sensitive-variable redaction के साथ), आपके architecture pattern को वर्गीकृत करता है (Java के 5 patterns A/B/C/D/E, Kotlin CQRS / multi-module, Next.js App vs. Pages Router, FSD, components-pattern), domains खोजता है, और मौजूद हर source file path का स्पष्ट allowlist बनाता है। Output: `project-analysis.json` — आगे जो होता है उसके लिए single source of truth।
+**1. Step A — Scanner (deterministic, कोई LLM नहीं)।** एक Node.js scanner project root को walk करता है, `package.json` / `build.gradle` / `pom.xml` / `pyproject.toml` पढ़ता है, `.env*` files parse करता है (`PASSWORD/SECRET/TOKEN/JWT_SECRET/...` जैसी sensitive variables को redact करते हुए), architecture pattern classify करता है (Java के 5 patterns A/B/C/D/E, Kotlin CQRS / multi-module, Next.js App vs Pages Router, FSD, components-pattern), domains discover करता है, और मौजूदा हर source file path का explicit allowlist बनाता है। इसका output है `project-analysis.json`, जो आगे की हर चीज़ के लिए single source of truth बन जाता है।
 
-**2. Step B — 4-Pass Claude पाइपलाइन (Step A के तथ्यों से प्रतिबंधित)।**
-- **Pass 1** प्रति domain group प्रतिनिधि फ़ाइलें पढ़ता है और प्रति domain ~50–100 परिपाटियाँ निकालता है — response wrappers, logging libraries, error handling, naming conventions, test patterns. प्रति domain group एक बार चलता है (`max 4 domains, 40 files per group`) ताकि context कभी overflow न हो।
-- **Pass 2** सभी per-domain analysis को project-wide picture में merge करता है और dominant convention चुनकर असहमतियाँ हल करता है।
-- **Pass 3** `CLAUDE.md` + `.claude/rules/` + `claudeos-core/standard/` + skills + guides लिखता है — stages में split (`3a` facts → `3b-core/3b-N` rules+standards → `3c-core/3c-N` skills+guides → `3d-aux` database+mcp-guide) ताकि `pass2-merged.json` बड़ा होने पर भी हर stage का prompt LLM के context window में fit हो। ≥16 domain वाले projects के लिए 3b/3c को ≤15-domain batches में sub-divide करता है।
-- **Pass 4** L4 memory layer (`decision-log.md`, `failure-patterns.md`, `compaction.md`, `auto-rule-update.md`) को seed करता है और universal scaffold rules जोड़ता है। Pass 4 को **`CLAUDE.md` संशोधित करने से प्रतिबंधित किया गया है** — Pass 3 का Section 8 authoritative है।
+**2. Step B — 4-Pass Claude pipeline (Step A के facts के दायरे में)।**
+- **Pass 1** हर domain group के representative files पढ़ता है और प्रति domain करीब 50–100 conventions निकालता है — response wrappers, logging libraries, error handling, naming conventions, test patterns वगैरह। यह domain group पर एक बार चलता है (`max 4 domains, 40 files per group`), इसलिए context कभी overflow नहीं होता।
+- **Pass 2** सारे per-domain analysis को project-wide picture में merge कर देता है, और जहाँ disagreement हो वहाँ dominant convention चुन लेता है।
+- **Pass 3** `CLAUDE.md`, `.claude/rules/`, `claudeos-core/standard/`, skills और guides लिखता है। यह stages में split होता है (`3a` facts → `3b-core/3b-N` rules+standards → `3c-core/3c-N` skills+guides → `3d-aux` database+mcp-guide), जिससे `pass2-merged.json` बड़ा होने पर भी हर stage का prompt LLM के context window में आ जाता है। 16 या उससे ज्यादा domains वाले projects के लिए 3b/3c को ≤15-domain batches में sub-divide कर दिया जाता है।
+- **Pass 4** L4 memory layer को seed करता है (`decision-log.md`, `failure-patterns.md`, `compaction.md`, `auto-rule-update.md`) और कुछ universal scaffold rules जोड़ता है। Pass 4 को **`CLAUDE.md` modify करने की इजाज़त नहीं है** — Pass 3 का Section 8 ही authoritative है।
 
-**3. Step C — Verification (deterministic, कोई LLM नहीं)।** पाँच validators output की जाँच करते हैं:
-- `claude-md-validator` — `CLAUDE.md` पर 25 संरचनात्मक checks (8 sections, H3/H4 counts, memory file uniqueness, T1 canonical heading invariant). Language-invariant: `--lang` से स्वतंत्र वही verdict।
-- `content-validator` — 10 content checks जिसमें path-claim verification (`STALE_PATH` fabricated `src/...` references को पकड़ता है) और MANIFEST drift detection शामिल हैं।
-- `pass-json-validator` — Pass 1/2/3/4 JSON well-formedness + stack-aware section count।
+**3. Step C — Verification (deterministic, कोई LLM नहीं)।** पाँच validators output check करते हैं:
+- `claude-md-validator` — `CLAUDE.md` पर 25 structural checks (8 sections, H3/H4 counts, memory file uniqueness, T1 canonical heading invariant)। यह language-invariant है, यानी `--lang` कोई भी हो, verdict same रहता है।
+- `content-validator` — 10 content checks, जिनमें path-claim verification (`STALE_PATH` invented `src/...` references पकड़ता है) और MANIFEST drift detection शामिल हैं।
+- `pass-json-validator` — Pass 1/2/3/4 की JSON well-formedness और stack-aware section count check।
 - `plan-validator` — plan ↔ disk consistency (legacy, v2.1.0 के बाद से ज़्यादातर no-op)।
-- `sync-checker` — 7 tracked dirs में disk ↔ `sync-map.json` registration consistency।
+- `sync-checker` — 7 tracked dirs पर disk ↔ `sync-map.json` registration consistency।
 
-तीन severity tiers (`fail` / `warn` / `advisory`) ताकि warnings कभी CI को LLM hallucinations पर deadlock न करें जिन्हें user मैन्युअल रूप से ठीक कर सकता है।
+तीन severity tiers (`fail` / `warn` / `advisory`) रखे गए हैं, ताकि जिन LLM hallucinations को user खुद ठीक कर सकता है, उनकी वजह से CI deadlock न हो जाए।
 
-जो invariant यह सब बाँधता है: **Claude केवल वही paths cite कर सकता है जो आपके कोड में वास्तव में मौजूद हैं**, क्योंकि Step A उसे एक finite allowlist देता है। यदि LLM फिर भी कुछ आविष्कार करने की कोशिश करता है (दुर्लभ, लेकिन कुछ seeds पर होता है), Step C docs ship होने से पहले उसे पकड़ लेता है।
+पूरी चीज़ एक invariant पर टिकी है: **Claude वही paths cite कर सकता है जो आपके code में असल में मौजूद हैं**, क्योंकि Step A उसे एक finite allowlist देता है। फिर भी अगर LLM कुछ invent करने की कोशिश करे (कुछ खास seeds पर rare है, मगर होता है), तो Step C docs ship होने से पहले उसे पकड़ लेता है।
 
-per-pass details, marker-based resume, Claude Code के `.claude/` sensitive-path block के लिए staged-rules workaround, और stack detection internals के लिए, [docs/hi/architecture.md](docs/hi/architecture.md) देखें।
+हर pass के internals, marker-based resume, Claude Code के `.claude/` sensitive-path block का staged-rules workaround और stack detection की अंदरूनी logic के लिए [docs/hi/architecture.md](docs/hi/architecture.md) देखें।
 
 ---
 
 ## Supported Stacks
 
-12 stacks, आपकी प्रोजेक्ट फ़ाइलों से स्वतः पहचाने जाते हैं:
+12 stacks, project files से auto-detected।
 
 **Backend:** Java/Spring Boot · Kotlin/Spring Boot · Node/Express · Node/Fastify · Node/NestJS · Python/Django · Python/FastAPI · Python/Flask
 
 **Frontend:** Node/Next.js · Node/Vite · Angular · Vue/Nuxt
 
-मल्टी-stack प्रोजेक्ट (उदाहरण: Spring Boot backend + Next.js frontend) सीधे काम करते हैं।
+Multi-stack projects (जैसे Spring Boot backend + Next.js frontend) भी out of the box चलते हैं।
 
-पहचान नियमों और प्रत्येक scanner क्या निकालता है, के लिए [docs/hi/stacks.md](docs/hi/stacks.md) देखें।
+Detection rules और हर scanner क्या निकालता है, यह [docs/hi/stacks.md](docs/hi/stacks.md) में है।
 
 ---
 
-## दैनिक Workflow
+## दैनिक वर्कफ़्लो
 
-तीन commands ~95% उपयोग को कवर करते हैं:
+ये तीन commands ~95% use cases cover कर लेते हैं।
 
 ```bash
-# प्रोजेक्ट पर पहली बार
+# Project पर पहली बार
 npx claudeos-core init
 
-# आपके द्वारा standards या rules मैन्युअल रूप से संपादित करने के बाद
+# जब standards या rules manually edit किए हों
 npx claudeos-core lint
 
-# हेल्थ चेक (commit से पहले, या CI में चलाएँ)
+# Health check (commit से पहले या CI में)
 npx claudeos-core health
 ```
 
-memory layer के रखरखाव के लिए दो और:
-
-```bash
-# failure-patterns लॉग का compaction (समय-समय पर चलाएँ)
-npx claudeos-core memory compact
-
-# बार-बार होने वाले failure patterns को proposed rules में बढ़ाएँ
-npx claudeos-core memory propose-rules
-```
-
-प्रत्येक command के पूर्ण options के लिए, [docs/hi/commands.md](docs/hi/commands.md) देखें।
+हर command के पूरे options [docs/hi/commands.md](docs/hi/commands.md) में हैं। Memory layer commands (`memory compact`, `memory propose-rules`) नीचे [Memory Layer](#memory-layer-वैकल्पिक-दीर्घकालिक-प्रोजेक्ट्स-के-लिए) section में documented हैं।
 
 ---
 
-## यह क्या अलग बनाता है
+## क्या इसे अलग बनाता है
 
-अधिकांश Claude Code documentation tools विवरण से उत्पन्न करते हैं (आप टूल को बताते हैं, टूल Claude को बताता है)। ClaudeOS-Core आपके वास्तविक स्रोत कोड से उत्पन्न करता है (टूल पढ़ता है, टूल Claude को बताता है क्या पुष्ट है, Claude केवल वही लिखता है जो पुष्ट है)।
+ज़्यादातर Claude Code documentation tools description से generate करते हैं — आप tool को बताते हैं, tool Claude को बताता है। ClaudeOS-Core इसके बजाय आपके actual source code से generate करता है। Tool खुद code पढ़ता है, फिर Claude को बताता है कि क्या confirmed है, और Claude सिर्फ उतना ही लिखता है।
 
-तीन ठोस परिणाम:
+इसके तीन ठोस नतीजे हैं।
 
-1. **Deterministic stack detection.** एक ही प्रोजेक्ट + एक ही कोड = एक ही आउटपुट। "इस बार Claude ने अलग नतीजा दिया" नहीं।
-2. **No invented paths.** Pass 3 prompt हर अनुमत स्रोत path को स्पष्ट रूप से सूचीबद्ध करता है; Claude ऐसे paths का उल्लेख नहीं कर सकता जो मौजूद नहीं हैं।
-3. **Multi-stack aware.** Backend और frontend domains एक ही run में अलग-अलग analysis prompts का उपयोग करते हैं।
+1. **Deterministic stack detection.** Same project + same code = same output। "इस बार Claude थोड़ा अलग roll हो गया" वाली बात नहीं होती।
+2. **No invented paths.** Pass 3 prompt में हर allowed source path explicitly listed होता है, इसलिए Claude ऐसे paths cite ही नहीं कर सकता जो मौजूद नहीं हैं।
+3. **Multi-stack aware.** एक ही run में backend और frontend domains अलग-अलग analysis prompts use करते हैं।
 
-अन्य tools के साथ side-by-side scope तुलना के लिए, [docs/hi/comparison.md](docs/hi/comparison.md) देखें। तुलना **प्रत्येक टूल क्या करता है** के बारे में है, न कि **कौन बेहतर है** — अधिकांश पूरक हैं।
+दूसरे tools के साथ side-by-side scope comparison के लिए [docs/hi/comparison.md](docs/hi/comparison.md) देखें। यह तुलना **हर tool क्या करता है** के बारे में है, **कौन सा बेहतर है** के बारे में नहीं — असल में ज़्यादातर एक-दूसरे के complementary हैं।
 
 ---
 
-## Verification (post-generation)
+## सत्यापन (जनरेशन के बाद)
 
-Claude द्वारा docs लिखने के बाद, कोड उन्हें सत्यापित करता है। पाँच अलग-अलग validators:
+Claude docs लिख चुकने के बाद उन्हें code verify करता है। पाँच अलग-अलग validators।
 
-| Validator | यह क्या जाँचता है | किसके द्वारा चलाया जाता है |
+| Validator | क्या check करता है | किसके through चलता है |
 |---|---|---|
-| `claude-md-validator` | CLAUDE.md की संरचनात्मक अपरिवर्तनीयताएँ (8 sections, language-invariant) | `claudeos-core lint` |
-| `content-validator` | Path दावे वास्तव में मौजूद हैं; manifest स्थिरता | `health` (advisory) |
-| `pass-json-validator` | Pass 1 / 2 / 3 / 4 आउटपुट well-formed JSON हैं | `health` (warn) |
-| `plan-validator` | सहेजी गई plan disk से मेल खाती है | `health` (fail-on-error) |
-| `sync-checker` | Disk फ़ाइलें `sync-map.json` registrations से मेल खाती हैं (orphaned/unregistered detection) | `health` (fail-on-error) |
+| `claude-md-validator` | CLAUDE.md structural invariants (8 sections, language-invariant) | `claudeos-core lint` |
+| `content-validator` | Path claims सच में मौजूद हैं या नहीं; manifest consistency | `health` (advisory) |
+| `pass-json-validator` | Pass 1 / 2 / 3 / 4 outputs well-formed JSON हैं या नहीं | `health` (warn) |
+| `plan-validator` | Saved plan disk से match करता है या नहीं | `health` (fail-on-error) |
+| `sync-checker` | Disk files `sync-map.json` registrations से match करते हैं (orphaned/unregistered detection) | `health` (fail-on-error) |
 
-`health-checker` चार runtime validators को तीन-tier severity (fail / warn / advisory) के साथ orchestrate करता है और CI के लिए उपयुक्त code के साथ exit होता है। `claude-md-validator` `lint` command के माध्यम से अलग चलता है क्योंकि संरचनात्मक drift एक re-init संकेत है, न कि soft warning। कभी भी चलाएँ:
+`health-checker` इन चारों runtime validators को three-tier severity (fail / warn / advisory) के साथ orchestrate करता है और CI के लिए सही exit code लौटाता है। `claude-md-validator` अलग से `lint` command से चलता है, क्योंकि structural drift सिर्फ soft warning नहीं, re-init का signal है। जब मन हो, चला लीजिए।
 
 ```bash
 npx claudeos-core health
 ```
 
-प्रत्येक validator के विस्तृत checks के लिए, [docs/hi/verification.md](docs/hi/verification.md) देखें।
+हर validator के individual checks [docs/hi/verification.md](docs/hi/verification.md) में detail से दिए हैं।
 
 ---
 
-## Memory Layer (वैकल्पिक, लंबे चलने वाले प्रोजेक्ट के लिए)
+## Memory Layer (वैकल्पिक, दीर्घकालिक प्रोजेक्ट्स के लिए)
 
-v2.0 के बाद, ClaudeOS-Core चार फ़ाइलों के साथ एक `claudeos-core/memory/` फ़ोल्डर लिखता है:
+ऊपर वाली scaffolding pipeline के अलावा, ClaudeOS-Core उन projects के लिए एक `claudeos-core/memory/` folder भी seed करता है जिनका context एक session से ज़्यादा खिंचता है। यह वैकल्पिक है — अगर आपको सिर्फ `CLAUDE.md` और rules चाहिए तो इसे ignore कर सकते हैं।
 
-- `decision-log.md` — append-only "हमने X के बजाय Y क्यों चुना"
-- `failure-patterns.md` — frequency/importance स्कोर के साथ बार-बार होने वाली त्रुटियाँ
-- `compaction.md` — समय के साथ memory को कैसे auto-compact किया जाता है
-- `auto-rule-update.md` — पैटर्न जो नए rules बनने चाहिए
+चार files हैं, और सब Pass 4 लिखता है।
 
-आप `npx claudeos-core memory propose-rules` चलाकर Claude से हाल के failure patterns देखने और जोड़ने के लिए नए rules सुझाने को कह सकते हैं।
+- `decision-log.md` — append-only "हमने X की जगह Y क्यों चुना", `pass2-merged.json` से seed होता है
+- `failure-patterns.md` — frequency / importance scores के साथ बार-बार आने वाली errors
+- `compaction.md` — समय के साथ memory कैसे auto-compact होती है
+- `auto-rule-update.md` — वो patterns जिन्हें नए rules बनना चाहिए
 
-memory model और lifecycle के लिए, [docs/hi/memory-layer.md](docs/hi/memory-layer.md) देखें।
+इस layer को समय के साथ maintain करने के लिए दो commands हैं।
+
+```bash
+# Failure-patterns log compact करें (समय-समय पर चलाएँ)
+npx claudeos-core memory compact
+
+# बार-बार आने वाले failure patterns को proposed rules में promote करें
+npx claudeos-core memory propose-rules
+```
+
+Memory model और lifecycle की पूरी बात [docs/hi/memory-layer.md](docs/hi/memory-layer.md) में है।
 
 ---
 
 ## FAQ
 
-**Q: क्या मुझे Claude API key की ज़रूरत है?**
-A: नहीं। ClaudeOS-Core आपके मौजूदा Claude Code installation का उपयोग करता है — यह आपकी मशीन पर `claude -p` को prompts pipe करता है। कोई अतिरिक्त खाते नहीं।
+**Q: क्या Claude API key चाहिए?**
+A: नहीं। ClaudeOS-Core आपके पहले से installed Claude Code को ही use करता है और आपकी machine पर `claude -p` को prompts pipe करता है। कोई extra account नहीं चाहिए।
 
-**Q: क्या यह मेरी मौजूदा CLAUDE.md या `.claude/rules/` को overwrite करेगा?**
-A: नए प्रोजेक्ट पर पहली run: यह उन्हें बनाता है। `--force` के बिना पुनः चलाने पर आपके edits सुरक्षित रहते हैं — पिछली run के pass markers का पता लगाया जाता है और passes छोड़ दिए जाते हैं। `--force` के साथ पुनः चलाने पर सब कुछ wipe और regenerate होता है (आपके edits खो जाते हैं — `--force` का यही मतलब है)। [docs/hi/safety.md](docs/hi/safety.md) देखें।
+**Q: क्या यह मेरी मौजूदा CLAUDE.md या `.claude/rules/` overwrite कर देगा?**
+A: नए project पर पहली run में यह इन्हें create करता है। `--force` के बिना दोबारा चलाने पर आपके edits बच जाते हैं, क्योंकि पिछली run के pass markers detect होकर वो passes skip हो जाते हैं। `--force` के साथ चलाने पर सब wipe होकर regenerate होता है, यानी edits भी चले जाते हैं — `--force` का मतलब ही यही है। ज़्यादा detail [docs/hi/safety.md](docs/hi/safety.md) में।
 
-**Q: मेरा stack समर्थित नहीं है। क्या मैं एक जोड़ सकता हूँ?**
-A: हाँ। नए stacks को ~3 prompt templates + एक domain scanner चाहिए। 8-step गाइड के लिए [CONTRIBUTING.md](CONTRIBUTING.md) देखें।
+**Q: मेरा stack supported नहीं है, क्या जोड़ सकते हैं?**
+A: हाँ। नए stack के लिए करीब 3 prompt templates और एक domain scanner चाहिए। 8-step guide के लिए [CONTRIBUTING.md](CONTRIBUTING.md) देखें।
 
-**Q: मैं Korean (या अन्य भाषा) में docs कैसे उत्पन्न करूँ?**
-A: `npx claudeos-core init --lang ko`. 10 भाषाएँ समर्थित: en, ko, ja, zh-CN, es, vi, hi, ru, fr, de.
+**Q: कोरियाई (या किसी और भाषा) में docs कैसे generate करूँ?**
+A: `npx claudeos-core init --lang ko`। 10 भाषाएँ supported हैं: en, ko, ja, zh-CN, es, vi, hi, ru, fr, de।
 
 **Q: क्या यह monorepos के साथ काम करता है?**
-A: हाँ — Turborepo (`turbo.json`), pnpm workspaces (`pnpm-workspace.yaml`), Lerna (`lerna.json`), और npm/yarn workspaces (`package.json#workspaces`) stack-detector द्वारा पहचाने जाते हैं। प्रत्येक app को अपना analysis मिलता है। अन्य monorepo layouts (उदा., NX) विशेष रूप से नहीं पहचाने जाते, लेकिन सामान्य `apps/*/` और `packages/*/` patterns प्रति-stack scanners द्वारा अभी भी उठाए जाते हैं।
+A: हाँ। Turborepo (`turbo.json`), pnpm workspaces (`pnpm-workspace.yaml`), Lerna (`lerna.json`) और npm/yarn workspaces (`package.json#workspaces`) — इन्हें stack-detector पहचान लेता है, और हर app के लिए अलग analysis होता है। बाकी monorepo layouts (जैसे NX) explicitly detect नहीं होते, मगर generic `apps/*/` और `packages/*/` patterns per-stack scanners फिर भी pick कर लेते हैं।
+
+**Q: अगर Claude Code ऐसे rules generate कर दे जिनसे मैं असहमत हूँ?**
+A: सीधे edit कर दीजिए। उसके बाद `npx claudeos-core lint` चलाकर check कर लीजिए कि CLAUDE.md अभी भी structurally valid है या नहीं। आगे की `init` runs पर (बिना `--force` के) आपके edits बच जाते हैं, क्योंकि resume mechanism उन passes को skip करता है जिनके markers मौजूद हैं।
+
+**Q: Bugs कहाँ report करूँ?**
+A: [GitHub Issues](https://github.com/claudeos-core/claudeos-core/issues) पर। Security issues के लिए [SECURITY.md](SECURITY.md) देखें।
+
+---
 
-**Q: यदि Claude Code ऐसे rules उत्पन्न करता है जिनसे मैं असहमत हूँ?**
-A: उन्हें सीधे संपादित करें। फिर यह पुष्टि करने के लिए `npx claudeos-core lint` चलाएँ कि CLAUDE.md अभी भी संरचनात्मक रूप से वैध है। आपके edits बाद की `init` runs पर सुरक्षित रहते हैं (`--force` के बिना) — resume तंत्र उन passes को छोड़ देता है जिनके markers मौजूद हैं।
+## यदि इसने आपका समय बचाया
 
-**Q: मैं bugs कहाँ रिपोर्ट करूँ?**
-A: [GitHub Issues](https://github.com/claudeos-core/claudeos-core/issues)। सुरक्षा मुद्दों के लिए [SECURITY.md](SECURITY.md) देखें।
+GitHub पर एक ⭐ project को visible रखता है और दूसरों को भी इसे ढूँढने में मदद करता है। Issues, PRs और stack template contributions — सबका स्वागत है। Detail के लिए [CONTRIBUTING.md](CONTRIBUTING.md) देखें।
 
 ---
 
-## Documentation
+## दस्तावेज़ीकरण
 
 | विषय | यह पढ़ें |
 |---|---|
-| 4-pass पाइपलाइन कैसे काम करती है (diagram से अधिक गहरा) | [docs/hi/architecture.md](docs/hi/architecture.md) |
-| Architecture के दृश्य diagrams (Mermaid) | [docs/hi/diagrams.md](docs/hi/diagrams.md) |
-| Stack detection — प्रत्येक scanner क्या देखता है | [docs/hi/stacks.md](docs/hi/stacks.md) |
+| 4-pass pipeline कैसे काम करती है (diagram से ज़्यादा गहराई से) | [docs/hi/architecture.md](docs/hi/architecture.md) |
+| Architecture के visual diagrams (Mermaid) | [docs/hi/diagrams.md](docs/hi/diagrams.md) |
+| Stack detection — हर scanner क्या देखता है | [docs/hi/stacks.md](docs/hi/stacks.md) |
 | Memory layer — decision logs और failure patterns | [docs/hi/memory-layer.md](docs/hi/memory-layer.md) |
-| सभी 5 validators विस्तार से | [docs/hi/verification.md](docs/hi/verification.md) |
+| पाँचों validators detail में | [docs/hi/verification.md](docs/hi/verification.md) |
 | हर CLI command और option | [docs/hi/commands.md](docs/hi/commands.md) |
-| मैन्युअल installation (बिना `npx` के) | [docs/hi/manual-installation.md](docs/hi/manual-installation.md) |
+| Manual installation (बिना `npx` के) | [docs/hi/manual-installation.md](docs/hi/manual-installation.md) |
 | Scanner overrides — `.claudeos-scan.json` | [docs/hi/advanced-config.md](docs/hi/advanced-config.md) |
-| सुरक्षा: re-init पर क्या सुरक्षित रहता है | [docs/hi/safety.md](docs/hi/safety.md) |
-| समान tools के साथ तुलना (scope, गुणवत्ता नहीं) | [docs/hi/comparison.md](docs/hi/comparison.md) |
-| त्रुटियाँ और रिकवरी | [docs/hi/troubleshooting.md](docs/hi/troubleshooting.md) |
+| Safety: re-init पर क्या-क्या preserved रहता है | [docs/hi/safety.md](docs/hi/safety.md) |
+| Similar tools के साथ तुलना (scope, quality नहीं) | [docs/hi/comparison.md](docs/hi/comparison.md) |
+| Errors और recovery | [docs/hi/troubleshooting.md](docs/hi/troubleshooting.md) |
 
 ---
 
 ## योगदान
 
-योगदान का स्वागत है — stack समर्थन जोड़ना, prompts बेहतर बनाना, bugs ठीक करना। [CONTRIBUTING.md](CONTRIBUTING.md) देखें।
+Contributions का स्वागत है — stack support जोड़ना, prompts सुधारना, bugs ठीक करना, सब कुछ। Detail के लिए [CONTRIBUTING.md](CONTRIBUTING.md) देखें।
 
-Code of Conduct और सुरक्षा नीति के लिए, [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) और [SECURITY.md](SECURITY.md) देखें।
+Code of Conduct और security policy [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) और [SECURITY.md](SECURITY.md) में हैं।
 
-## License
+## लाइसेंस
 
-[ISC](LICENSE) — किसी भी उपयोग के लिए मुफ़्त, व्यावसायिक सहित।
+[ISC License](LICENSE)। Commercial use सहित किसी भी काम के लिए free है। © 2025–2026 ClaudeOS-Core contributors।
 
 ---
 
-<sub>[@claudeos-core](https://github.com/claudeos-core) द्वारा सावधानी से निर्मित। यदि इसने आपका समय बचाया है, GitHub पर एक ⭐ इसे दृश्यमान बनाए रखता है।</sub>
+<sub>[claudeos-core](https://github.com/claudeos-core) team द्वारा maintained। Issues और PRs <https://github.com/claudeos-core/claudeos-core> पर भेजें।</sub>