openclaw path

oc:// एड्रेसिंग स्कीम तक शेल पहुँच: एड्रेस किए जा सकने वाले वर्कस्पेस फ़ाइलों (markdown, jsonc, jsonl, yaml/yml/lobster) का निरीक्षण और संपादन करने के लिए प्रकार के अनुसार डिस्पैच किया गया एक पथ सिंटैक्स। स्वयं होस्ट करने वाले उपयोगकर्ता, Plugin लेखक और एडिटर एक्सटेंशन इसका उपयोग किसी सीमित स्थान को पढ़ने, खोजने या अपडेट करने के लिए करते हैं, ताकि हर फ़ाइल के लिए अलग पार्सर स्वयं न बनाना पड़े।

path बंडल किए गए वैकल्पिक oc-path Plugin द्वारा प्रदान किया जाता है। पहले उपयोग से पहले इसे सक्षम करें:

openclaw plugins enable oc-path

CLI क्रियाएँ एड्रेसिंग मॉडल को प्रतिबिंबित करती हैं:

• resolve ठोस है और केवल एक मिलान करता है।
• find वाइल्डकार्ड, यूनियन, प्रेडिकेट और स्थितिगत विस्तार के लिए बहु-मिलान क्रिया है।
• set केवल ठोस पथ या प्रविष्टि मार्कर स्वीकार करता है; वाइल्डकार्ड पैटर्न लिखने से पहले अस्वीकार कर दिए जाते हैं।
• validate किसी फ़ाइल सिस्टम पहुँच के बिना पथ को पार्स करता है।
• emit किसी फ़ाइल को पार्स + उत्सर्जन के माध्यम से राउंड-ट्रिप करता है (बाइट-निष्ठा निदान)।

इसका उपयोग क्यों करें

OpenClaw की स्थिति मानव-संपादित markdown, टिप्पणियों वाली JSONC कॉन्फ़िगरेशन, केवल-परिशिष्ट JSONL लॉग और YAML वर्कफ़्लो/स्पेक फ़ाइलों में फैली होती है। स्क्रिप्ट, हुक और एजेंटों को अक्सर इन फ़ाइलों से केवल एक छोटा मान चाहिए होता है: कोई फ्रंटमैटर कुंजी, कोई Plugin सेटिंग, कोई लॉग रिकॉर्ड फ़ील्ड, कोई YAML चरण या किसी नामित अनुभाग के अंतर्गत कोई बुलेट आइटम।

openclaw path इन कॉलर को प्रत्येक फ़ाइल प्रकार के लिए एकबारगी grep, regex या पार्सर के बजाय एक स्थिर पता देता है। उसी oc:// पथ को टर्मिनल से सत्यापित, रिज़ॉल्व, खोजा, ड्राई-रन और लिखा जा सकता है, जिससे सीमित ऑटोमेशन समीक्षायोग्य और पुनः चलाने योग्य बना रहता है। यह फ़ाइल के शेष भाग को सुरक्षित रखता है, इसलिए एक लीफ़ लिखने से उसकी टिप्पणियाँ, लाइन एंडिंग या आस-पास की फ़ॉर्मैटिंग प्रभावित नहीं होती।

इसका उपयोग तब करें जब इच्छित चीज़ का कोई तार्किक पता हो, लेकिन फ़ाइल का आकार-प्रकार अलग-अलग हो:

• कोई हुक टिप्पणियों वाली JSONC से एक सेटिंग पढ़ता है और मान वापस लिखते समय टिप्पणियाँ नहीं खोता।
• कोई रखरखाव स्क्रिप्ट JSONL लॉग में हर मिलते-जुलते इवेंट फ़ील्ड को पूरा लॉग किसी कस्टम पार्सर में लोड किए बिना खोजती है।
• कोई एडिटर स्लग द्वारा markdown अनुभाग या बुलेट आइटम पर जाता है, फिर रिज़ॉल्व की गई सटीक लाइन रेंडर करता है।
• कोई एजेंट छोटा वर्कस्पेस संपादन लागू करने से पहले उसे ड्राई-रन करता है, जिसमें बदले हुए बाइट समीक्षा में दिखाई देते हैं।

सामान्य संपूर्ण-फ़ाइल संपादनों, समृद्ध कॉन्फ़िगरेशन माइग्रेशन या मेमोरी-विशिष्ट लेखन के लिए openclaw path का उपयोग न करें; इनके लिए स्वामी कमांड या Plugin का उपयोग करना चाहिए। path छोटे, एड्रेस किए जा सकने वाले फ़ाइल ऑपरेशनों के लिए है, जहाँ दोहराने योग्य टर्मिनल कमांड एक और विशिष्ट पार्सर से बेहतर होता है।

इसका उपयोग कैसे किया जाता है

मानव-संपादित कॉन्फ़िगरेशन फ़ाइल से एक मान पढ़ें:

openclaw path resolve 'oc://config.jsonc/plugins/github/enabled'

डिस्क को छुए बिना लेखन का पूर्वावलोकन करें:

openclaw path set 'oc://config.jsonc/plugins/github/enabled' 'true' --dry-run

केवल-परिशिष्ट JSONL लॉग में मिलते-जुलते रिकॉर्ड खोजें:

openclaw path find 'oc://session.jsonl/[event=tool_call]/name'

markdown में किसी निर्देश को लाइन नंबर के बजाय अनुभाग और आइटम द्वारा एड्रेस करें:

openclaw path resolve 'oc://AGENTS.md/runtime-safety/openclaw-gateway'

CI या प्रीफ़्लाइट स्क्रिप्ट में, स्क्रिप्ट के पढ़ने या लिखने से पहले पथ सत्यापित करें:

openclaw path validate 'oc://AGENTS.md/tools/$last/risk'

ये कमांड शेल स्क्रिप्ट में कॉपी किए जा सकने के लिए बनाए गए हैं। जब किसी कॉलर को संरचित आउटपुट चाहिए तब --json का और जब कोई व्यक्ति परिणाम का निरीक्षण कर रहा हो तब --human का उपयोग करें।

यह कैसे काम करता है

1. oc:// पते को स्लॉट में पार्स करता है: फ़ाइल, अनुभाग, आइटम, फ़ील्ड और एक वैकल्पिक सत्र क्वेरी।
2. लक्ष्य एक्सटेंशन से फ़ाइल-प्रकार अडैप्टर चुनता है (.md, .jsonc, .json, .jsonl, .ndjson, .yaml, .yml, .lobster)।
3. स्लॉट को उस फ़ाइल प्रकार की संरचना के अनुसार रिज़ॉल्व करता है: markdown हेडिंग/आइटम, JSONC ऑब्जेक्ट कुंजियाँ/ऐरे इंडेक्स, JSONL लाइन रिकॉर्ड या YAML मैप/सीक्वेंस Node।
4. set के लिए, संपादित बाइट को उसी अडैप्टर के माध्यम से उत्सर्जित करता है, ताकि फ़ाइल के अपरिवर्तित भाग अपनी टिप्पणियाँ, लाइन एंडिंग और आस-पास की फ़ॉर्मैटिंग बनाए रखें, जहाँ संबंधित प्रकार इसका समर्थन करता है।

resolve और set को एक ठोस लक्ष्य चाहिए। find अन्वेषणात्मक क्रिया है: यह वाइल्डकार्ड, यूनियन, प्रेडिकेट और क्रमसूचक को ठोस मिलानों में विस्तारित करती है, जिन्हें लिखने के लिए कोई एक चुनने से पहले देखा जा सकता है।

उपकमांड

वैश्विक फ़्लैग

validate केवल --json / --human लेता है; यह फ़ाइल सिस्टम तक पहुँच नहीं करता, इसलिए --cwd और --file लागू नहीं होते।

oc:// सिंटैक्स

oc://FILE/SECTION/ITEM/FIELD?session=SCOPE

स्लॉट नियम: field के लिए item आवश्यक है, और item के लिए section आवश्यक है। सभी चार स्लॉट में:

• उद्धृत सेगमेंट — "a/b.c", / और . विभाजकों के बावजूद सुरक्षित रहता है। सामग्री बाइट-लिटरल होती है; उद्धरणों के भीतर " और \ की अनुमति नहीं है। फ़ाइल स्लॉट भी उद्धरण-जागरूक है: oc://"skills/email-drafter"/Tools/$last, skills/email-drafter को एकल फ़ाइल पथ मानता है।
• प्रेडिकेट — [k=v], [k!=v], [k<v], [k<=v], [k>v], [k>=v]। सांख्यिक ऑपरेटरों के लिए दोनों पक्षों का सीमित संख्याओं में रूपांतरित होना आवश्यक है।
• यूनियन — {a,b,c} किसी भी विकल्प से मेल खाता है।
• वाइल्डकार्ड — * (एकल उप-सेगमेंट) और ** (शून्य या अधिक, पुनरावर्ती)। find इन्हें स्वीकार करता है; resolve और set इन्हें अस्पष्ट मानकर अस्वीकार करते हैं।
• स्थितिगत — $first / $last पहले / अंतिम इंडेक्स या घोषित कुंजी में रिज़ॉल्व होते हैं।
• क्रमसूचक — दस्तावेज़ क्रम के अनुसार Nवें मिलान के लिए #N।
• प्रविष्टि मार्कर — कुंजीयुक्त / इंडेक्सयुक्त प्रविष्टि के लिए +, +key, +nnn (set के साथ उपयोग करें)।
• सत्र स्कोप — ?session=cron-daily आदि। स्लॉट नेस्टिंग से स्वतंत्र। सत्र मान रॉ होते हैं, प्रतिशत-डिकोड नहीं किए जाते; उनमें नियंत्रण वर्ण या आरक्षित क्वेरी सीमांकक (?, &, %) नहीं हो सकते।

उद्धृत, प्रेडिकेट या यूनियन सेगमेंट के बाहर आरक्षित वर्ण (?, &, %) अस्वीकार किए जाते हैं। नियंत्रण वर्ण (U+0000-U+001F, U+007F) session क्वेरी मान सहित कहीं भी अस्वीकार किए जाते हैं।

कैनोनिकल पथों के लिए formatOcPath(parseOcPath(path)) === path की गारंटी है। पहले गैर-रिक्त session= मान को छोड़कर गैर-कैनोनिकल क्वेरी पैरामीटर अनदेखे किए जाते हैं।

कठोर सीमाएँ: पथ अधिकतम 4096 बाइट, अधिकतम 4 स्लॉट (फ़ाइल/अनुभाग/आइटम/ फ़ील्ड), प्रति स्लॉट अधिकतम 64 डॉटयुक्त उप-सेगमेंट और गहरे JSON पथों के लिए अधिकतम 256 नेस्टेड ट्रैवर्सल स्तर तक सीमित है। अलग से, 16 MiB से बड़ी किसी भी JSONC/JSON फ़ाइल इनपुट को पार्स करने के बजाय पार्स निदान के साथ अस्वीकार किया जाता है, ऐसी फ़ाइल लोड करने वाली किसी भी क्रिया के लिए।

फ़ाइल प्रकार के अनुसार एड्रेसिंग

resolve एक संरचित मिलान लौटाता है: root, node, leaf या insertion-point, साथ में 1-आधारित लाइन नंबर। लीफ़ मानों को पाठ और एक leafType के रूप में प्रस्तुत किया जाता है, ताकि Plugin लेखक प्रत्येक प्रकार के AST आकार पर निर्भर हुए बिना पूर्वावलोकन रेंडर कर सकें।

म्यूटेशन अनुबंध

set एक ठोस लक्ष्य लिखता है:

• Markdown फ्रंटमैटर मान और - key: value आइटम फ़ील्ड स्ट्रिंग लीफ़ हैं। Markdown प्रविष्टियाँ अनुभाग, फ्रंटमैटर कुंजियाँ, या अनुभाग आइटम जोड़ती हैं और बदली गई फ़ाइल के लिए एक कैनोनिकल Markdown स्वरूप रेंडर करती हैं। अनुभाग बॉडी को set के माध्यम से समग्र रूप में लिखा नहीं जा सकता।
• JSONC लीफ़ लेखन स्ट्रिंग मान को मौजूदा लीफ़ प्रकार में कोअर्स करता है (string, परिमित number, true/false, या null)। जब JSONC/JSON/JSONL लीफ़ प्रतिस्थापन को <value> को JSON के रूप में पार्स करना चाहिए और उसका स्वरूप बदल सकता है, जैसे किसी स्ट्रिंग secret-ref शॉर्टहैंड को ऑब्जेक्ट से बदलना, तब --value-json का उपयोग करें। JSONC ऑब्जेक्ट और ऐरे प्रविष्टियाँ <value> को JSON के रूप में पार्स करती हैं और सामान्य लीफ़ लेखन के लिए jsonc-parser संपादन पथ का उपयोग करती हैं, जिससे टिप्पणियाँ और आस-पास का फ़ॉर्मैटिंग सुरक्षित रहता है।
• JSONL लीफ़ लेखन किसी पंक्ति के भीतर JSONC की तरह कोअर्स करता है। पूरी पंक्ति का प्रतिस्थापन और जोड़ना <value> को JSON के रूप में पार्स करता है। रेंडर किया गया JSONL फ़ाइल की प्रमुख LF/CRLF पंक्ति-अंत परंपरा को बनाए रखता है (फ़ाइल की नई पंक्तियों में बहुमत के आधार पर, इसलिए अधिकतर-CRLF वाली फ़ाइल कुछ इक्का-दुक्का LF होने पर भी CRLF ही रहती है)।
• YAML लीफ़ लेखन मौजूदा स्केलर प्रकार में कोअर्स करता है (string, परिमित number, true/false, या null)। YAML प्रविष्टियाँ मैप/सीक्वेंस अपडेट के लिए बंडल किए गए yaml पैकेज के दस्तावेज़ API का उपयोग करती हैं। पार्सर त्रुटियों वाले विकृत YAML दस्तावेज़ों में परिवर्तन करने से पहले parse-error के साथ अस्वीकार कर दिया जाता है।

जब सटीक बाइट मायने रखते हों, तो उपयोगकर्ता-दृश्य लेखन से पहले --dry-run का उपयोग करें। JSONC और YAML संपादन मौजूदा दस्तावेज़ को पैच करते हैं (jsonc-parser या yaml दस्तावेज़ API के माध्यम से), इसलिए अछूते बाइट सामान्यतः बने रहते हैं; किसी भी संपादन पर Markdown फ़ाइल को उसकी पार्स की गई संरचना से दोबारा बनाता है, जिससे बदले गए लीफ़ के बाहर का आनुषंगिक फ़ॉर्मैटिंग सामान्यीकृत हो सकता है। यदि आप पूर्ण रेंडर की गई फ़ाइल के बजाय केंद्रित पहले/बाद के पैच के रूप में पूर्वावलोकन चाहते हैं, तो --diff जोड़ें।

उदाहरण

# पथ सत्यापित करें (फ़ाइल सिस्टम अभिगम नहीं)openclaw path validate 'oc://AGENTS.md/Tools/$last/risk' # लीफ़ पढ़ेंopenclaw path resolve 'oc://gateway.jsonc/version' # वाइल्डकार्ड खोजopenclaw path find 'oc://session.jsonl/*/event' --file ./logs/session.jsonl # लेखन का ड्राई रन करेंopenclaw path set 'oc://gateway.jsonc/version' '2.0' --dry-run # यूनिफ़ाइड डिफ़ के रूप में लेखन का ड्राई रन करेंopenclaw path set 'oc://gateway.jsonc/version' '2.0' --dry-run --diff # लेखन लागू करेंopenclaw path set 'oc://gateway.jsonc/version' '2.0' # बाइट-निष्ठा राउंड-ट्रिप (निदान)openclaw path emit ./AGENTS.md

व्याकरण के और उदाहरण:

# / या . वाली कुंजियों को उद्धरण चिह्नों में रखेंopenclaw path resolve 'oc://config.jsonc/agents.defaults.models/"anthropic/claude-opus-4-7"/alias' # गहरे JSON/JSONC पथ स्लैश खंडों का उपयोग कर सकते हैं; वे डॉट वाले उपखंडों में सामान्यीकृत होते हैंopenclaw path set 'oc://openclaw.json/agents/list/0/tools/exec/security' 'allowlist' --dry-run # JSONC लीफ़ को पार्स किए गए ऑब्जेक्ट से बदलेंopenclaw path set 'oc://openclaw.json/gateway/auth/token' '{"source":"file","provider":"secrets","id":"/test"}' --value-json --dry-run # JSONC चाइल्ड पर प्रेडिकेट खोजopenclaw path find 'oc://config.jsonc/plugins/[enabled=true]/id' # JSONC ऐरे में प्रविष्ट करेंopenclaw path set 'oc://config.jsonc/items/+1' '{"id":"new","enabled":true}' --dry-run # JSONC ऑब्जेक्ट कुंजी प्रविष्ट करेंopenclaw path set 'oc://config.jsonc/plugins/+github' '{"enabled":true}' --dry-run # JSONL इवेंट जोड़ेंopenclaw path set 'oc://session.jsonl/+' '{"event":"checkpoint","ok":true}' --file ./logs/session.jsonl # अंतिम JSONL मान पंक्ति रिज़ॉल्व करेंopenclaw path resolve 'oc://session.jsonl/$last/event' --file ./logs/session.jsonl # YAML वर्कफ़्लो चरण रिज़ॉल्व करेंopenclaw path resolve 'oc://workflow.yaml/steps/0/id' # YAML स्केलर अपडेट करेंopenclaw path set 'oc://workflow.yaml/steps/$last/id' 'classify-renamed' --dry-run # Markdown फ्रंटमैटर को संबोधित करेंopenclaw path resolve 'oc://AGENTS.md/[frontmatter]/name' # Markdown फ्रंटमैटर प्रविष्ट करेंopenclaw path set 'oc://AGENTS.md/[frontmatter]/+description' 'Agent instructions' --dry-run # Markdown आइटम फ़ील्ड खोजेंopenclaw path find 'oc://SKILL.md/Tools/*/send_email' # सत्र-स्कोप वाला पथ सत्यापित करेंopenclaw path validate 'oc://AGENTS.md/Tools/$last/risk?session=cron-daily'

फ़ाइल प्रकार के अनुसार विधियाँ

सभी प्रकारों में वही पाँच क्रियाएँ काम करती हैं; संबोधन योजना फ़ाइल एक्सटेंशन के आधार पर प्रेषित करती है।

Markdown

<!-- frontmatter.md -->---name: drafterdescription: ईमेल ड्राफ़्टिंग एजेंटtier: core---## उपकरण- gh: GitHub CLI- curl: HTTP क्लाइंट- send_email: सक्षम

$ openclaw path resolve 'oc://x.md/[frontmatter]/tier' --file frontmatter.md --humanलीफ़ @ L4: "core" (स्ट्रिंग) $ openclaw path resolve 'oc://x.md/tools/gh/gh' --file frontmatter.md --humanलीफ़ @ L9: "GitHub CLI" (स्ट्रिंग) $ openclaw path find 'oc://x.md/tools/*' --file frontmatter.md --humanoc://x.md/tools/* के लिए 3 मिलान:  oc://x.md/tools/gh           →  नोड @ L9 [md-item]  oc://x.md/tools/curl         →  नोड @ L10 [md-item]  oc://x.md/tools/send-email   →  नोड @ L11 [md-item]

[frontmatter] प्रेडिकेट YAML फ्रंटमैटर ब्लॉक को संबोधित करता है; tools स्लग के माध्यम से ## Tools शीर्षक से मेल खाता है, और स्रोत में अंडरस्कोर का उपयोग होने पर भी आइटम लीफ़ अपना स्लग स्वरूप बनाए रखते हैं (send_email, send-email बन जाता है)।

JSONC

// config.jsonc{  "plugins": {    "github": {"enabled": true, "role": "vcs"},    "slack":  {"enabled": false, "role": "chat"}  }}

$ openclaw path resolve 'oc://config.jsonc/plugins/github/enabled' --file config.jsonc --humanलीफ़ @ L4: "true" (बूलियन) $ openclaw path set 'oc://config.jsonc/plugins/slack/enabled' 'true' --file config.jsonc --dry-run--dry-run: /…/config.jsonc में 142 बाइट लिखे जाते{  "plugins": {    "github": {"enabled": true, "role": "vcs"},    "slack":  {"enabled": true, "role": "chat"}  }}

JSONC संपादन jsonc-parser से होकर गुजरते हैं, इसलिए set के दौरान टिप्पणियाँ और रिक्त स्थान बने रहते हैं। कमिट करने से पहले बाइट का निरीक्षण करने के लिए इसे पहले --dry-run के साथ चलाएँ। .json फ़ाइलें .jsonc के समान एडाप्टर और संपादन पथ का उपयोग करती हैं।

JSONL

{"event":"start","userId":"u1","ts":1}{"event":"action","userId":"u1","ts":2}{"event":"end","userId":"u1","ts":3}

$ openclaw path find 'oc://session.jsonl/[event=action]/userId' --file session.jsonl --humanoc://session.jsonl/[event=action]/userId के लिए 1 मिलान:  oc://session.jsonl/L2/userId  →  लीफ़ @ L2: "u1" (स्ट्रिंग) $ openclaw path resolve 'oc://session.jsonl/L2/ts' --file session.jsonl --humanलीफ़ @ L2: "2" (संख्या)

प्रत्येक पंक्ति एक रिकॉर्ड है। जब आपको पंक्ति संख्या ज्ञात न हो, तो प्रेडिकेट ([event=action]) से संबोधित करें, और ज्ञात होने पर कैनोनिकल LN खंड से। .ndjson फ़ाइलें .jsonl के समान एडाप्टर का उपयोग करती हैं।

YAML

# workflow.yamlname: inbox-triagesteps:  - id: fetch    command: gmail.search  - id: classify    command: openclaw.invoke

$ openclaw path resolve 'oc://workflow.yaml/steps/0/id' --file workflow.yaml --humanलीफ़ @ L3: "fetch" (स्ट्रिंग) $ openclaw path set 'oc://workflow.yaml/steps/$last/id' 'classify-renamed' --file workflow.yaml --dry-run--dry-run: /…/workflow.yaml में 99 बाइट लिखे जातेname: inbox-triagesteps:  - id: fetch    command: gmail.search  - id: classify-renamed    command: openclaw.invoke

YAML हाथ से बनाए गए पार्सर के बजाय yaml पैकेज के Document API का उपयोग करता है, इसलिए सामान्य पार्स/एमिट राउंड-ट्रिप टिप्पणियों और लेखन स्वरूप को बनाए रखते हैं, जबकि रिज़ॉल्व किए गए पथ JSONC के समान मैप-कुंजी / सीक्वेंस-इंडेक्स मॉडल का उपयोग करते हैं। वही एडाप्टर .yaml, .yml, और .lobster फ़ाइलों को संभालता है।

सबकमांड संदर्भ

resolve <oc-path>

एक लीफ़ या नोड पढ़ें। वाइल्डकार्ड अस्वीकार किए जाते हैं—उनके लिए find का उपयोग करें। मिलान पर 0, साफ़ तौर पर कोई मिलान न होने पर 1, और पार्स त्रुटि या अस्वीकृत पैटर्न पर 2 के साथ बाहर निकलता है।

openclaw path resolve 'oc://AGENTS.md/tools/gh/risk' --humanopenclaw path resolve 'oc://gateway.jsonc/server/port' --json

find <pattern>

वाइल्डकार्ड / प्रेडिकेट / यूनियन पैटर्न के प्रत्येक मिलान को सूचीबद्ध करें। कम-से-कम एक मिलान पर 0, शून्य मिलान पर 1 के साथ बाहर निकलता है। फ़ाइल-स्लॉट वाइल्डकार्ड OC_PATH_FILE_WILDCARD_UNSUPPORTED के साथ अस्वीकार किए जाते हैं—एक ठोस फ़ाइल दें (बहु-फ़ाइल ग्लॉबिंग एक अनुवर्ती सुविधा है)।

openclaw path find 'oc://AGENTS.md/tools/**/risk'openclaw path find 'oc://session.jsonl/[event=action]/userId'openclaw path find 'oc://config.jsonc/plugins/{github,slack}/enabled'

set <oc-path> <value>

एक लीफ़ लिखें। फ़ाइल को छुए बिना लिखे जाने वाले बाइट का पूर्वावलोकन करने के लिए इसे --dry-run के साथ जोड़ें। यूनिफ़ाइड डिफ़ पूर्वावलोकन के लिए --diff जोड़ें। सफल लेखन पर 0, सब्सट्रेट द्वारा अस्वीकार किए जाने पर 1 (उदाहरण के लिए, सेंटिनल गार्ड सक्रिय होना), और पार्स त्रुटियों पर 2 के साथ बाहर निकलता है।

openclaw path set 'oc://gateway.jsonc/version' '2.0' --dry-runopenclaw path set 'oc://gateway.jsonc/version' '2.0' --dry-run --diffopenclaw path set 'oc://gateway.jsonc/version' '2.0'openclaw path set 'oc://AGENTS.md/Tools/+gh/risk' 'low'

यदि नाम वाला चाइल्ड पहले से मौजूद न हो, तो +key प्रविष्टि मार्कर उसे बनाता है; क्रमशः इंडेक्स वाली और जोड़ने वाली प्रविष्टि के लिए +nnn और केवल + काम करते हैं।

validate <oc-path>

केवल पार्स जाँच। कोई फ़ाइल सिस्टम अभिगम नहीं। यह तब उपयोगी है, जब आप वेरिएबल प्रतिस्थापित करने से पहले पुष्टि करना चाहते हों कि टेम्पलेट पथ सुगठित है, या जब आप डीबगिंग के लिए संरचनात्मक विश्लेषण चाहते हों:

$ openclaw path validate 'oc://AGENTS.md/tools/gh' --humanमान्य: oc://AGENTS.md/tools/gh  फ़ाइल:    AGENTS.md  अनुभाग: tools  आइटम:    gh

मान्य होने पर 0, अमान्य होने पर 1 (संरचित code और message के साथ), और आर्ग्युमेंट त्रुटियों पर 2 के साथ बाहर निकलता है।

emit <file>

प्रति-प्रकार पार्सर और एमिटर के माध्यम से फ़ाइल का राउंड-ट्रिप करें। सही फ़ाइल पर आउटपुट इनपुट के बाइट-समान होना चाहिए; विचलन पार्सर बग या सेंटिनल सक्रिय होने का संकेत देता है। वास्तविक इनपुट पर सब्सट्रेट व्यवहार को डीबग करने के लिए उपयोगी है।

openclaw path emit ./AGENTS.mdopenclaw path emit ./gateway.jsonc --json

निकास कोड

आउटपुट मोड

openclaw path TTY-जागरूक है: टर्मिनल पर मानव-पठनीय आउटपुट, और stdout को पाइप या रीडायरेक्ट करने पर JSON। --json और --human स्वतः-पहचान को ओवरराइड करते हैं।

टिप्पणियाँ

• set सब्सट्रेट के emit पथ के माध्यम से बाइट्स लिखता है, जो रिडैक्शन-सेंटिनल गार्ड को स्वचालित रूप से लागू करता है। ऐसा लीफ़ जिसमें __OPENCLAW_REDACTED__ मौजूद हो (यथावत या सबस्ट्रिंग के रूप में), लिखते समय अस्वीकार कर दिया जाता है।
• JSONC पार्सिंग और लीफ़ संपादन Plugin-स्थानीय jsonc-parser निर्भरता का उपयोग करते हैं, इसलिए सामान्य लीफ़ लेखन में टिप्पणियाँ और फ़ॉर्मैटिंग हस्तनिर्मित पार्सर/री-रेंडर पथ से गुज़रने के बजाय संरक्षित रहती हैं।
• path अंतिम-ज्ञात-सही (LKG) कॉन्फ़िगरेशन ट्रैकिंग या पुनर्प्राप्ति से अवगत नहीं है; उस जीवनचक्र का स्वामित्व कहीं और है। यदि path के माध्यम से संपादित की गई फ़ाइल भी LKG-ट्रैक की जाती है, तो अगला कॉन्फ़िगरेशन पठन तय करता है कि उसे प्रोमोट किया जाए या पुनर्प्राप्त किया जाए; path संपादन को उस फ़ाइल पर किसी भी अन्य प्रत्यक्ष लेखन के समान मानें।

संबंधित

• CLI संदर्भ