OC Path प्लगइन

बंडल किया गया oc-path Plugin openclaw path CLI को oc:// workspace-file एड्रेसिंग स्कीम के लिए जोड़ता है। यह OpenClaw रिपॉज़िटरी में extensions/oc-path/ के अंतर्गत आता है, लेकिन opt-in है — install/build इसे तब तक निष्क्रिय छोड़ता है जब तक आप इसे सक्षम नहीं करते।

oc:// पते workspace file के अंदर किसी एक leaf (या leaves के wildcard set) की ओर संकेत करते हैं। Plugin आज चार तरह की फ़ाइलों को समझता है:

• markdown (.md, .mdx): frontmatter, sections, items, fields
• jsonc (.jsonc, .json5, .json): comments और formatting संरक्षित रहती है
• jsonl (.jsonl, .ndjson): line-oriented records
• yaml (.yaml, .yml, .lobster): YAML document API के ज़रिए map/sequence/scalar nodes

Self-hosters और editor extensions CLI का उपयोग SDK के विरुद्ध सीधे scripting किए बिना किसी एक leaf को पढ़ने या लिखने के लिए करते हैं; agents और hooks इसे deterministic substrate मानते हैं ताकि byte-fidelity round-trips और redaction sentinel guard सभी kinds पर समान रूप से लागू हों।

इसे क्यों सक्षम करें

oc-path को तब सक्षम करें जब आप scripts, hooks, या local agent tooling को हर file shape के लिए parser बनाए बिना workspace state के किसी सटीक हिस्से की ओर संकेत करवाना चाहते हों। एक oc:// पता markdown frontmatter key, section item, JSONC config leaf, JSONL event field, या YAML workflow step को नाम दे सकता है।

यह maintainer workflows के लिए महत्वपूर्ण है, जहाँ change छोटा, auditable, और repeatable होना चाहिए: एक value inspect करें, matching records ढूँढें, write का dry-run करें, फिर comments, line endings, और आसपास की formatting को वैसा ही रखते हुए केवल वही leaf apply करें। इसे opt-in Plugin रखने से power users को addressing substrate मिलता है, बिना उन installs के core में parser dependencies या CLI surface डाले जिन्हें इसकी कभी ज़रूरत नहीं होती।

इसे सक्षम करने के सामान्य कारण:

• Local automation: shell scripts अलग-अलग markdown, JSONC, JSONL, और YAML parsing code रखने के बजाय openclaw path … --json से एक workspace value resolve या update कर सकते हैं।
• Agent-visible edits: agent लिखने से पहले किसी एक addressed leaf के लिए dry-run diff दिखा सकता है, जिसकी review free-form file rewrite से आसान होती है।
• Editor integrations: editor oc://AGENTS.md/tools/gh को heading text से अनुमान लगाए बिना exact markdown node और line number पर map कर सकता है।
• Diagnostics: emit फ़ाइल को parser और emitter के ज़रिए round-trip करता है, ताकि automated edits पर निर्भर होने से पहले आप जाँच सकें कि file kind byte-stable है या नहीं।

ठोस उदाहरण:

# Is the GitHub plugin enabled in this config?openclaw path resolve 'oc://config.jsonc/plugins/github/enabled' --json # Which tool-call names appear in this session log?openclaw path find 'oc://session.jsonl/[event=tool_call]/name' --json # What bytes would this tiny config edit write?openclaw path set 'oc://config.jsonc/plugins/github/enabled' 'true' --dry-run

Plugin जानबूझकर higher-level semantics का owner नहीं है। Memory plugins अब भी memory writes के owner हैं, config commands अब भी full config management के owner हैं, और LKG logic अब भी restore/promotion का owner है। oc-path वह संकीर्ण addressing और byte-preserving file operation layer है जिसके आसपास वे higher-level tools बन सकते हैं।

यह कहाँ चलता है

Plugin उस host पर openclaw CLI के अंदर in-process चलता है जहाँ आप command invoke करते हैं। इसे running Gateway की ज़रूरत नहीं होती और यह कोई network sockets नहीं खोलता — हर verb उस file पर pure transform है जिसकी ओर आप इसे point करते हैं।

Plugin metadata extensions/oc-path/openclaw.plugin.json में रहता है:

{  "id": "oc-path",  "name": "OC Path",  "activation": {    "onStartup": false,    "onCommands": ["path"]  },  "commandAliases": [{ "name": "path", "kind": "cli" }]}

onStartup: false Plugin को Gateway hot path से बाहर रखता है। onCommands: ["path"] CLI को बताता है कि पहली बार openclaw path … चलाने पर Plugin को lazily load करे, इसलिए जो installs इस verb का कभी उपयोग नहीं करते, उन्हें कोई cost नहीं देनी पड़ती।

सक्षम करें

openclaw plugins enable oc-path

Gateway को restart करें (यदि आप एक चलाते हैं) ताकि manifest snapshot नई state उठा ले। Bare openclaw path invocations उसी host पर तुरंत काम करते हैं — CLI मांग पर Plugin load करता है।

Disable करने के लिए:

openclaw plugins disable oc-path

Dependencies

सभी parser dependencies Plugin-local हैं — oc-path सक्षम करने से core runtime में नए packages नहीं आते:

JSONL hand-rolled रहता है — line-oriented parsing किसी भी dependency से सरल है, और per-line JSONC parse पहले ही jsonc-parser से गुजरता है।

यह क्या देता है

CLI आज एकमात्र public surface है। substrate verbs Plugin के लिए private हैं; consumers CLI का उपयोग करते हैं (या SDK के विरुद्ध अपना Plugin बनाते हैं)।

दूसरे plugins से संबंध

• memory-*: memory writes oc-path से नहीं, memory plugins से गुजरते हैं। oc-path generic file substrate है; memory plugins इसके ऊपर अपनी semantics layer करते हैं।
• LKG: path Last-Known-Good config restore के बारे में नहीं जानता। यदि कोई file LKG-tracked है, तो अगला observe call तय करता है कि promote करना है या recover; LKG promote/recover lifecycle के ज़रिए atomic multi-set के लिए set --batch LKG-recovery substrate के साथ planned है।

Safety

set substrate के emit path के ज़रिए raw bytes लिखता है, जो redaction-sentinel guard को automatically apply करता है। ऐसा leaf जिसमें __OPENCLAW_REDACTED__ (verbatim या substring के रूप में) हो, write time पर OC_EMIT_SENTINEL के साथ refuse कर दिया जाता है। CLI अपने द्वारा print किए गए किसी भी human या JSON output से literal sentinel को scrub भी करता है, उसे [REDACTED] से replace करता है ताकि terminal captures और pipelines marker leak न करें।

संबंधित

• openclaw path CLI reference
• Plugins manage करें
• Plugins बनाना