अन्य भाषाओं में: English, Español, Português, 日本語, Deutsch, Français, 한국어, 简体中文, Italiano · हिन्दी में सभी गाइड
खुलासा: Carbon Forge को हम 100monkeys.ai पर बनाते हैं, इसलिए इसे बनाने वाले का विवरण मानकर पढ़ें। इस गाइड का मसौदा हमारे एक AI एजेंट ने सार्वजनिक दस्तावेज़ों से तैयार किया, ख़ासकर Working in lanes और Code and files on the substrate से, और कंपनी ने इसकी समीक्षा की; यह हिन्दी संस्करण मूल अंग्रेज़ी गाइड का अनुवाद है। नीचे का हर कॉल दस्तावेज़ों का अपना उदाहरण है, और उद्धरण अंग्रेज़ी में हैं, अनुवाद साथ में। जहाँ दस्तावेज़ कोई सवाल खुला छोड़ते हैं, आख़िरी हिस्सा यह बताता है।
एक ही changeset क्यों
दस्तावेज़ों का होम पेज इकाई की परिभाषा देता है: "A changeset is many writes landed as one: every page, atom, code tree and library entry it names is written in one transaction under one intent, the changeset's intent, or nothing is written" (Welcome to Carbon)। (changeset कई लेखन हैं जो एक की तरह लैंड होते हैं: वह जिस भी पेज, atom, कोड ट्री और लाइब्रेरी एंट्री का नाम लेता है, वह एक ही ट्रांज़ैक्शन में एक ही intent के तहत लिखी जाती है, या कुछ भी नहीं लिखा जाता।) कोड और गद्य एक ही रिकॉर्ड की इकाइयाँ हैं, इसलिए पाठक को पुराने पेज के बगल में नया कोड कभी नहीं मिलता, और revert दोनों को एक साथ वापस ले जाता है।
आपको ऐसा टोकन चाहिए जो lane और ट्री लिख सके; दस्तावेज़ इस काम के लिए SCM agent प्रीसेट का नाम लेते हैं।
चरण 1. पता करें कि trunk सुरक्षित है या नहीं
workspaces.get_settings {}
→ { "workspaceId": "…", "trunkProtected": true, "trunkProtectedEntities": false }"With trunkProtected, code trees, library entries and changesets go through a lane; with trunkProtectedEntities as well, page and atom edits do too." (trunkProtected के साथ कोड ट्री, लाइब्रेरी एंट्री और changeset एक lane से होकर जाते हैं; साथ में trunkProtectedEntities हो तो पेज और atom के बदलाव भी।) दोनों हालात में यहाँ lane ही सही ढाँचा है: दस्तावेज़ इसे तब इस्तेमाल करते हैं जब "a change should be seen whole before it lands." (कोई बदलाव लैंड होने से पहले पूरा देखा जाना चाहिए।)
चरण 2. बदलाव के लिए एक lane खोलें
lanes.create { "label": "agent/7/fix-login" }label स्लैश से अलग किए छोटे अक्षरों वाले हिस्सों से बनता है और खुली lanes में अनोखा होता है। "A lane costs nothing to open and holds no copy, so one per task, or one per agent, is the expected use." (lane खोलने में कुछ ख़र्च नहीं होता और उसमें कोई कॉपी नहीं होती, इसलिए हर काम या हर एजेंट के लिए एक lane ही अपेक्षित इस्तेमाल है।) owner दें, ताकि lane को लिखना, सुलझाना और लैंड करना सिर्फ़ आपके हाथ में रहे।
चरण 3. lane पर कोड बदलें
trees.apply_patch { "path": "app", "operations": [ { "op": "patch", "entry_path": "src/login.ts", "old_string": "password", "new_string": "magicLink" } ], "intent": "fix: accept magic links", "lane": "agent/7/fix-login" }label को lane के रूप में दें और "the write is held on the lane as a patch against the trunk" (लेखन lane पर trunk के मुक़ाबले एक patch के रूप में रखा जाता है): "the trunk is not written." (trunk पर कुछ नहीं लिखा जाता।) trees.apply_patch सिर्फ़ अपने ऑपरेशन भेजता है (फ़ाइल के अंदर एक बदलाव, एक लेखन, एक हटाना या एक खिसकाना); trees.put ट्री की पूरी एंट्री सूची भेजता है। दोनों हालात में "the lane keeps only what differs." (lane सिर्फ़ वही रखती है जो अलग है।)
चरण 4. उसी lane पर उसे दर्ज करने वाला पेज बदलें
pages.apply_patch { "pathOrId": "guides/login", "old_string": "Sign in with a password.", "new_string": "Sign in with a magic link.", "lane": "agent/7/fix-login" }वही label, इसलिए पेज का बदलाव कोड के बगल में इंतज़ार करता है। अगर बदलाव किसी पेज का नाम भी बदलता है, तो pages.move भी lane लेता है, और "a rename belongs to the change that needs it." (नाम बदलना उसी बदलाव का हिस्सा है जिसे उसकी ज़रूरत है।) स्क्रीनशॉट भी इसी तरह library.put_at_path और label के साथ जाता है।
चरण 5. पढ़ें कि lane क्या बनाएगी
किसी पढ़ने वाले कॉल को वही lane दें और "the answer is the trunk as it stands now with the lane's patches applied, composed on the call" (जवाब trunk है जैसा वह अभी है, lane के patch लगाकर, कॉल के समय जोड़ा हुआ): पेज के लिए pages.read, कोड के लिए trees.get, trees.diff या trees.grep। फिर पूरे की समीक्षा करें:
lanes.diff { "label": "agent/7/fix-login" }
lanes.get { "label": "agent/7/fix-login" }lanes.diff जवाब देता है "entity by entity, the trunk's section and the lane's" (इकाई दर इकाई, trunk का हिस्सा और lane का); lanes.get patch, टकराव और landable बताता है: "open, at least one live patch, no conflict." (खुली, कम से कम एक जीवित patch, कोई टकराव नहीं।) ऐप में /<workspace>/lanes/<label> यही दिखाता है, हर बदली टेक्स्ट फ़ाइल को unified diff के रूप में। जो समीक्षक lanes.export पढ़कर उसके composition hash पर मंज़ूरी देता है, वह "has approved exactly that change." (ठीक उसी बदलाव को मंज़ूर कर चुका है।)
चरण 6. किसी भी टकराव का जवाब दें
अगर इस बीच किसी ने trunk पर पेज या फ़ाइल की वही पंक्तियाँ बदल दीं, तो patch टकराव में है, और "nothing merges by itself." (कुछ भी अपने आप नहीं मिलता।) lanes.conflicts patch, पहले का हिस्सा, trunk का अभी का हिस्सा और उसे बदलने वाले changeset देता है। lanes.resolve से जवाब दें या lanes.drop_patch से patch छोड़ दें। फ़ाइल के अंदर का बदलाव "replays on the trunk's current file, so two agents changing different parts of one file both land." (trunk की मौजूदा फ़ाइल पर फिर से लगता है, इसलिए एक ही फ़ाइल के अलग हिस्से बदलने वाले दो एजेंट दोनों लैंड होते हैं।)
चरण 7. एक बार, एक intent के साथ लैंड करें
lanes.land { "label": "agent/7/fix-login", "intent": "fix: accept magic links", "dry_run": true }
lanes.land { "label": "agent/7/fix-login", "intent": "fix: accept magic links" }पहले dry run चलाएँ, फिर लैंडिंग। "Every live patch is replayed as one changeset whose intent is lane agent/7/fix-login: fix: accept magic links" (हर जीवित patch उसी intent वाले एक changeset के रूप में फिर से लगाया जाता है), अपने ट्रांज़ैक्शन में दोबारा जाँचा जाता है और "refused whole, with every conflict named, if anything moved." (अगर कुछ भी खिसका हो तो पूरा अस्वीकार किया जाता है, हर टकराव के नाम के साथ।) intent को feat, fix, docs, chore या revert से शुरू करें, तो रिलीज़ नोट्स उसे उसी शब्द के तहत समूह में रखते हैं। idempotency_key भेजें, तो टाइमआउट के बाद दोबारा कोशिश "answers the first landing's result instead of landing twice." (दो बार लैंड करने के बजाय पहली लैंडिंग का नतीजा लौटाती है।)
चरण 8. लैंडिंग को वापस पढ़ें
/<workspace>/changes/<id> खोलें: यह पूरा intent, करने वाला, जिस lane से लैंड हुआ वह, उसकी सील और उसकी एंट्री दिखाता है, कोड फ़ाइल और पेज साथ में। बदली हुई पंक्ति पर blame अब आपके लिखे intent के साथ जवाब देता है: trees.blame देता है "each line's revision, changeset, intent, actor and landing lane" (हर पंक्ति का revision, changeset, intent, करने वाला और लैंडिंग lane) (Code and files)। दोनों को एक साथ पलटने के लिए changesets.revert एक नया changeset लिखता है जो लैंडिंग की लिखी हर इकाई को बहाल करता है।
दस्तावेज़ किन सवालों का जवाब नहीं देते
- lane के बिना एक कॉल वाला रास्ता। lanes गाइड
changesets.applyको"targets": [ … ]के साथ दिखाती है, पर वहाँ target का ढाँचा नहीं बताती, इसलिए यह गाइड lane इस्तेमाल करती है। - कौन-सा पेज किस कोड को दर्ज करता है। यहाँ कुछ भी यह संबंध नहीं बनाता; इसे घोषित करना ही governed seams का काम है (नीचे संबंधित गाइड देखें)।