---
title: अवलोकन
description: >-
  Blume के सभी कमांड एक ही जगह पर, हर कमांड द्वारा स्वीकार किए जाने वाले फ़्लैग, और dev सर्वर चलते रहने के दौरान साइट को सत्यापित करने का तरीका।
---

```bash
blume <command> [options]
```

## कमांड [#commands]

| कमांड | विवरण |
| --- | --- |
| `blume init [dir]` | एक प्रोजेक्ट का ढाँचा तैयार करें (डिफ़ॉल्ट रूप से इंटरैक्टिव)। |
| `blume dev` | हॉट रीलोड के साथ dev सर्वर शुरू करें। |
| `blume build` | स्टैटिक (या सर्वर) साइट बिल्ड करें। |
| `blume preview` | पिछले बिल्ड का प्रीव्यू देखें। |
| `blume add <item>` | रजिस्ट्री से एक सोर्स कंपोनेंट इंस्टॉल करें। |
| `blume sync` | रिमोट कंटेंट सोर्स को दोबारा फ़ेच करें और फिर से जनरेट करें। |
| `blume eject` | रनटाइम को एक स्वतंत्र Astro ऐप में बदलें। |
| `blume check` | `astro check` से साइट की टाइप-चेकिंग करें। |
| [`blume doctor`](/docs/cli/doctor) | कॉन्फ़िग और कंटेंट से जुड़ी समस्याओं का निदान करें। |
| [`blume validate`](/docs/cli/validate) | अपने पूरे कंटेंट में लिंक सत्यापित करें। |
| [`blume audit`](/docs/cli/audit) | बिल्ड की गई साइट में SEO और स्वास्थ्य संबंधी समस्याओं का ऑडिट करें। |
| [`blume eval`](/docs/cli/evals) | डॉक्स का परीक्षण करें: एक एजेंट केवल डॉक्यूमेंटेशन के आधार पर आपके प्रश्नों के उत्तर देता है। |
| [`blume translate`](/docs/cli/translate) | एक लोकल एजेंट CLI की मदद से डॉक्स का कॉन्फ़िगर किए गए लोकेल में अनुवाद करें। |
| [`blume version [id]`](/docs/cli/version) | वर्तमान डॉक्स को एक संग्रहीत संस्करण के रूप में फ़्रीज़ करें (id न देने पर कॉन्फ़िगर किए गए संस्करणों की सूची दिखाई जाती है)। |
| [`blume migrate [source]`](/docs/migrating) | Claude Code या Codex की मदद से किसी Mintlify, Fumadocs, Docusaurus, Starlight या Nextra साइट को Blume पर ले जाएँ। |
| [`blume upgrade`](/docs/upgrading) | नए मेजर संस्करण पर जाएँ: `blume` का संस्करण बढ़ाएँ, फिर बचे हुए कॉन्फ़िग बदलावों की सूची देखें या उन्हें Claude Code या Codex को सौंप दें। |

## सामान्य फ़्लैग [#common-flags]

- `blume init` — टर्मिनल में यह आपसे कुछ प्रश्न पूछता है (प्रोजेक्ट कहाँ बनाना है, साइट का नाम, टेम्पलेट, कंटेंट सोर्स); नीचे दिया गया हर फ़्लैग अपने संबंधित प्रश्न का उत्तर पहले से दे देता है।
- `blume init --yes` — प्रॉम्प्ट छोड़ें और डिफ़ॉल्ट सेटिंग्स के साथ ढाँचा तैयार करें (CI में या जब stdin टर्मिनल न हो, तब भी यही व्यवहार होता है)।
- `blume init --content-dir <dir>` — कंटेंट फ़ोल्डर सेट करें (डिफ़ॉल्ट `docs`)।
- `blume init --template docs|api|sdk|changelog` — किसी स्टार्टर से ढाँचा तैयार करें (साधारण docs सीड के बजाय API संदर्भ, SDK या चेंजलॉग)।
- `blume init --package-manager npm|pnpm|yarn|bun` — किसी विशिष्ट पैकेज मैनेजर से इंस्टॉल करें और उसी के अनुसार अगले चरण प्रिंट करें (डिफ़ॉल्ट: वही पैकेज मैनेजर जिससे `blume init` चलाया गया था)।
- `blume init --no-install` — फ़ाइलें लिखें लेकिन डिपेंडेंसी इंस्टॉल को छोड़ दें; यह CI या कस्टम डिपेंडेंसी वर्कफ़्लो के लिए है। डिफ़ॉल्ट रूप से `blume init` पैकेज मैनेजर का इंस्टॉल चलाता है ताकि प्रोजेक्ट चलने के लिए तैयार रहे; यदि इंस्टॉल विफल हो जाता है, तो तैयार किया गया ढाँचा बना रहता है, दोबारा प्रयास करने का कमांड प्रिंट किया जाता है, और एग्ज़िट कोड शून्य से भिन्न होता है।
- `blume init --eject` — ढाँचा तैयार करें, फिर उसे एक स्वतंत्र Astro प्रोजेक्ट में इजेक्ट करें (`--no-install` के साथ, डिपेंडेंसी इंस्टॉल होने के बाद यह `blume eject` चलाने में आपका मार्गदर्शन करता है)।
- `blume dev --host --port <n> --open`
- `blume dev --content-dir <dir>` — `blume.config.ts` संपादित किए बिना किसी दूसरे कंटेंट फ़ोल्डर को स्कैन करें।
- `blume dev --debug` — समस्या निवारण के लिए विस्तृत Astro/Vite लॉगिंग।
- `blume dev --preview` / `blume build --preview` — ड्राफ़्ट और अप्रकाशित CMS कंटेंट शामिल करें।
- `blume build --no-strict` — डायग्नोस्टिक त्रुटियों के बावजूद बिल्ड करें। डिफ़ॉल्ट रूप से `blume build` किसी भी त्रुटि डायग्नोस्टिक पर विफल हो जाता है (exit 1), क्योंकि जिन पेजों का frontmatter सत्यापन विफल होता है, उन्हें आउटपुट से हटा दिया जाता है; `--no-strict` के साथ बिल्ड सफल होता है और बताता है कि कितने पेज गायब हैं। `blume dev --strict` dev में भी यही fail-fast व्यवहार चालू करता है।
- `blume build --analyze` — बिल्ड के बाद क्लाइंट JavaScript बंडल के आकार प्रिंट करें (सबसे बड़े पहले)।
- `blume build --budget-js <kb> --budget-css <kb>` — कुल क्लाइंट JavaScript/CSS के बजट से अधिक होने पर बिल्ड विफल करें, जिससे परफ़ॉर्मेंस लक्ष्य एक CI गेट बन जाता है।
- `blume build --isolated` — `.blume/` के बजाय एक अस्थायी `.blume-verify/` रनटाइम (और उसके अपने `dist/`) में बिल्ड करें, ताकि चल रहा `blume dev` सर्वर और आपका वास्तविक `dist/` अप्रभावित रहें। [dev सर्वर चलते समय सत्यापन](#verifying-while-the-dev-server-runs) देखें।
- `blume preview --host --port <n>` — प्रीव्यू सर्वर को बाइंड करें।
- `blume sync --force` — पहले कैश किया गया स्नैपशॉट हटाकर रिमोट सोर्स दोबारा फ़ेच करें।
- `blume add <item> --force` — पहले से मौजूद फ़ाइलों को ओवरराइट करें।
- `blume check --preview` — जाँच करते समय ड्राफ़्ट और अप्रकाशित CMS कंटेंट शामिल करें।
- `blume check --strict` — टाइप त्रुटियों के साथ-साथ कंटेंट डायग्नोस्टिक्स पर भी विफल करें।
- `blume check --isolated` — एक अस्थायी `.blume-verify/` रनटाइम में टाइप-चेक करें, ताकि चल रहा `blume dev` सर्वर अप्रभावित रहे। [dev सर्वर चलते समय सत्यापन](#verifying-while-the-dev-server-runs) देखें।
- `blume eject --yes` — पुष्टि वाला प्रॉम्प्ट छोड़ें।

जिन कमांड का अपना अलग पेज है, उनके सभी फ़्लैग उसी पेज पर सूचीबद्ध हैं: [`blume doctor`](/docs/cli/doctor), [`blume validate`](/docs/cli/validate), [`blume audit`](/docs/cli/audit), [`blume eval`](/docs/cli/evals), [`blume translate`](/docs/cli/translate), और [`blume version`](/docs/cli/version)। `blume validate`, `blume doctor`, `blume audit`, `blume eval` और `blume translate` CI और एडिटर इंटीग्रेशन के लिए stdout पर मशीन-पठनीय परिणाम प्रिंट करने हेतु `--json` स्वीकार करते हैं (डायग्नोस्टिक्स की संरचना के लिए [Validate](/docs/cli/validate#json-output) देखें); `build`, `check` और `dev` केवल टर्मिनल पर रिपोर्ट करते हैं। हर कमांड ऐसे फ़्लैग को अस्वीकार कर देता है जिसे वह स्वीकार नहीं करता, सबसे निकटतम मिलान का सुझाव देता है और अपने स्वीकार्य फ़्लैग सूचीबद्ध करता है, ताकि `--isolatd` जैसी टाइपिंग की गलती अनदेखी होने के बजाय विफल हो जाए।

## dev सर्वर चलते समय सत्यापन [#verifying-while-the-dev-server-runs]

`blume dev` जनरेट किए गए `.blume/` रनटाइम पर आधारित एक लाइव Astro सर्वर चलाता है और हर बदलाव पर उसे फिर से जनरेट करता है। `blume build` और `blume check` _उसी_ `.blume/` को फिर से जनरेट करते हैं, इसलिए dev सर्वर के चालू रहते इनमें से किसी को भी चलाने से वह दूषित हो जाएगा — इसीलिए दोनों एक त्रुटि के साथ चलने से इनकार कर देते हैं और शून्य से भिन्न कोड के साथ बाहर निकलते हैं:

```
A `blume dev` server is running at http://localhost:4321; building would
corrupt its .blume runtime. Reuse that server, stop it first, or re-run with
--isolated to build/verify against .blume-verify without touching it.
```

`--isolated` फ़्लैग इसका समाधान है। यह पूरे जनरेट किए गए रनटाइम (और `build` के मामले में, उसके आउटपुट `dist/`) को उसी स्तर की `.blume-verify/` डायरेक्टरी में स्थानांतरित कर देता है, ताकि सत्यापन के दौरान ऐसी कोई भी चीज़ न लिखी जाए जिस पर dev सर्वर — या आपका वास्तविक `dist/` — निर्भर हो:

```bash
# In a second terminal, while `blume dev` is running:
blume check --isolated   # fast: type-check the .astro/config changes
blume build --isolated   # thorough: full production render into .blume-verify/dist
```

`check --isolated` त्वरित विकल्प है (Astro टाइप + टेम्पलेट डायग्नोस्टिक्स, कोई `dist/` नहीं); `build --isolated` अधिक व्यापक विकल्प है जो रनटाइम रेंडर त्रुटियों को भी पकड़ता है। आइसोलेटेड बिल्ड डिप्लॉय के बाद वाले चरणों (सर्च इंडेक्स, होस्टेड-प्रोवाइडर सिंक, `llms.txt`, sitemap/robots, रीडायरेक्ट) को छोड़ देते हैं — सत्यापन में केवल यह पुष्टि करनी होती है कि साइट कंपाइल और रेंडर होती है, उसे प्रकाशित करना आवश्यक नहीं है। `--analyze` और `--budget-js`/`--budget-css` गेट फिर भी चलते हैं और आइसोलेटेड आउटपुट के आधार पर मापे जाते हैं। Blume आपकी `.gitignore` में `.blume-verify/` को स्वचालित रूप से जोड़ देता है।

यह विशेष रूप से तब उपयोगी है जब किसी कोडिंग एजेंट को बदलाव सत्यापित करने हों और आप dev सर्वर खुला रखना चाहते हों। फ़्लैग के बिना ही साधारण `blume build`/`blume check` को आइसोलेट करने के लिए — उदाहरण के लिए किसी एजेंट के शेल में — `BLUME_RUNTIME_DIR` को उस रनटाइम डायरेक्टरी पर सेट करें जिसका उपयोग करना है:

```bash
export BLUME_RUNTIME_DIR=.blume-verify
```

## टाइप-चेकिंग [#type-checking]

`blume check` आपके प्रोजेक्ट पर [`astro check`](https://docs.astro.build/en/reference/cli-reference/#astro-check) चलाता है। यह `.blume` रनटाइम को फिर से जनरेट करता है, Astro के कंटेंट टाइप सिंक करता है, और फिर सभी TypeScript त्रुटियों की रिपोर्ट करता है — आपकी `blume.config.ts` में, कस्टम `.astro` पेजों में, और उनके द्वारा इम्पोर्ट किए गए कंपोनेंट्स में। त्रुटियाँ होने पर यह शून्य से भिन्न कोड के साथ बाहर निकलता है, इसलिए यह CI में `typecheck` चरण के रूप में काम करता है:

```json title="package.json"
{
  "scripts": {
    "typecheck": "blume check"
  }
}
```

अपने प्रोजेक्ट रूट में Astro के कॉन्फ़िग को एक्सटेंड करने वाली एक `tsconfig.json` जोड़ें, ताकि आपके द्वारा लिखे गए पेज `blume/*` इम्पोर्ट और `blume:data` जैसे वर्चुअल मॉड्यूल को रिज़ॉल्व कर सकें:

```json title="tsconfig.json"
{
  "extends": "astro/tsconfigs/strict",
  "include": [".blume/.astro/types.d.ts", "**/*"]
}
```

प्रोजेक्ट में `tsconfig.json` न होने पर केवल जनरेट किए गए रनटाइम की ही जाँच होती है।