kin v0.3.6

AI एजेंट किसी बदलाव को लिख सकते हैं, उससे पहले कि कोई टीम यह स्थापित कर पाए कि वह किन चीज़ों को छूता है, क्या वह पहले के किसी सुधार को पलटता है, और उसके परिणाम कितनी दूर तक फैलते हैं। Git फ़ाइलों और लाइन इतिहास को दर्ज करता है। Kin सॉफ़्टवेयर को स्वयं entities, relations, changes और provenance के ग्राफ़ के रूप में दर्ज करता है, फिर मनुष्यों और एजेंटों को पूछताछ और समीक्षा के लिए एक semantic प्राधिकरण देता है। कोई बदलाव जिन चीज़ों को छूता है, वे merge होने से पहले दिख जाती हैं, और एजेंट रिपॉज़िटरी को दोबारा पढ़ने के बजाय सटीक संदर्भ से काम करते हैं।

Kin, AI-लिखित सॉफ़्टवेयर के लिए semantic system of record है। यह एक सार्वजनिक alpha है, जो आज एक स्थानीय CLI, daemon, MCP सर्वर, समीक्षा सतह और graph-समर्थित फ़ाइलसिस्टम प्रोजेक्शन के रूप में उपयोग योग्य है। यह pre-1.0 है, इसलिए कुछ खुरदरे किनारों और breaking changes की उम्मीद करें। किसी महत्वपूर्ण वर्कफ़्लो में अपनाने से पहले नवीनतम स्थिर रिलीज़ और वर्तमान सीमाएँ देखें।

इसे एक वास्तविक रिपॉज़िटरी पर देखें

ripgrep में एक-पंक्ति का signature परिवर्तन diff में हानिरहित दिखता है। किसी भी compiler के चलने से पहले kin impact से इसके बारे में पूछें, और यह बताता है कि संपादन किन चीज़ों तक पहुँचता है। बदले गए signature के callers पहले आते हैं, फिर वह सब कुछ जो उन callers के पीछे खिंच जाता है।

ripgrep commit e89fff89ac9af12e8d4ce9d5fd07beb408ca730f पर एक तैयार ग्राफ़ के विरुद्ध दर्ज किया गया। 3 hops के भीतर 13 प्रभावित entities, जिनमें बदले गए signature के 3 प्रत्यक्ष callers शामिल हैं। ग्राफ़ पहले से बनाया गया था। कोई compiler नहीं चला। सटीक कमांड: kinlab.ai/proof। कच्ची run निर्देशिका अभी सार्वजनिक नहीं है, इसलिए यह एक recipe है जिसे आप दोबारा चला सकते हैं, कोई trace नहीं जिसे आप audit कर सकें।

Kin वह उजागर करता है जिसे बदलाव छूता है। बदलाव सही है या नहीं, यह आपके compiler, टेस्ट और समीक्षा पर निर्भर रहता है। ग्राफ़ पहले से kin init द्वारा बनाया जाता है, और इसे बनाना ही महँगा हिस्सा है; उसके बाद, impact के सवालों के उत्तर graph की सच्चाई से मिलते हैं, न कि tree को दोबारा पढ़कर।

स्टैक

Kin एक ही सिस्टम है जिसमें कुछ स्पष्ट सार्वजनिक सतहें हैं:

टुकड़े एक साथ कैसे फिट होते हैं

Kin, AI-लिखित सॉफ़्टवेयर के लिए semantic system of record है, और नीचे के मानचित्र में सब कुछ या तो उस प्राधिकरण तक पहुँचता है या उसका समर्थन करता है। मनुष्य और AI एजेंट CLI, बंडल किए गए MCP सर्वर या VS Code एक्सटेंशन के माध्यम से आते हैं। तीनों एक ही daemon से पूछते हैं, और daemon tree को दोबारा पढ़ने के बजाय graph प्राधिकरण से उत्तर देता है। kin-vfs उसी ग्राफ़ को सामान्य फ़ाइलसिस्टम कॉल के माध्यम से वापस प्रोजेक्ट करता है, इसलिए editors, compilers और build systems फ़ाइलें देखते रहते हैं। Git ग्राफ़ के बगल में import और export सीमा के रूप में बैठता है, न कि उत्तर-पथ के रूप में, और KinLab उसी प्राधिकरण के ऊपर होस्टेड परत है।

flowchart TD
    people["Humans and AI agents"]

    subgraph surfaces["Access surfaces"]
        cli["kin CLI"]
        mcp["Kin MCP server"]
        editor["kin-editor for VS Code"]
    end

    daemon["kin daemon"]
    authority["Graph authority<br/>entities, relations, changes, provenance"]
    db["kin-db<br/>graph storage, snapshots,<br/>index, text and vector search"]
    prims["kin-model, kin-blobs, kin-search,<br/>kin-vector, kin-infer, kin-lsp"]
    vfs["kin-vfs<br/>transparent file projection"]
    tools["Editors, compilers, build systems"]
    git["Git<br/>import and export boundary"]
    kinlab["KinLab<br/>hosted collaboration and control plane"]

    people --> cli
    people --> mcp
    people --> editor
    cli --> daemon
    mcp --> daemon
    editor --> daemon
    daemon --> authority
    authority --> db
    db --> prims
    authority <-->|"kin init imports, kin git export"| git
    authority -->|"publish and sync"| kinlab
    authority --> vfs
    vfs --> tools

उन सतहों के नीचे वे परतें हैं जिनसे सिस्टम बना है:

ये एक ही सिस्टम की कार्यान्वयन परतें हैं, अलग-अलग उत्पाद नहीं जिन्हें नया उपयोगकर्ता जोड़कर इकट्ठा करे। इनमें से कोई भी अलग से स्थापित नहीं होता।

ओपन सोर्स और Kin पारिस्थितिकी तंत्र

Kin का मूल Apache-2.0 के अंतर्गत ओपन सोर्स है: kin, kin-db, kin-vfs और kin-editor, साथ ही सहायक लाइब्रेरीज़ kin-model, kin-blobs, kin-search, kin-vector, kin-infer, kin-lsp और kin-actions।

KinLab इस ओपन कोर पर निर्मित एक स्वामित्व (proprietary) उत्पाद है: ऊपर वर्णित होस्टेड सहयोग और control-plane परत।

वही सीमा इस बात पर भी लागू होती है कि benchmark कार्य कैसे साझा किया जाता है। benchmark विनिर्देश और एक स्वतंत्र, निर्भरता-मुक्त bundle सत्यापक सार्वजनिक हैं, ताकि किसी दावे की जाँच उस सिस्टम तक पहुँच के बिना की जा सके जिसने उसे उत्पन्न किया। runner और proof अवसंरचना जो सीलबंद evidence bundles उत्पन्न करती है (orchestration, pinned-release proof gate और होस्टेड मापन वातावरण) अभी के लिए निजी बनी हुई है। spec और verifier पहले खुलते हैं; runner बाद में खुल सकता है।

सबसे छोटा graph-समर्थित पथ

1. Kin स्थापित करें और कॉन्फ़िगर करें

macOS या Linux पर:

curl -fsSL https://get.kinlab.dev/install | sh
exec "$SHELL" -l
kin setup --intent agent

इंस्टॉलर नवीनतम स्थिर रिलीज़ को हल करता है, उसके प्रकाशित SHA-256 checksum को सत्यापित करता है, प्रबंधित बाइनरी को ~/.kin के अंतर्गत स्थापित करता है और setup लॉन्च करता है। स्पष्ट agent intent चलाने से पता लगाए गए समर्थित क्लाइंटों के लिए अंतर्निर्मित MCP सर्वर कॉन्फ़िगर हो जाता है। MCP कॉन्फ़िगरेशन के बिना CLI और फ़ाइलसिस्टम उपयोग के लिए --intent local का उपयोग करें, या VS Code पथ के लिए --intent editor का।

केवल setup-प्रबंधित एकीकरण हटाने के लिए, kin setup uninstall चलाएँ। डिफ़ॉल्ट प्रबंधित रूट (~/.kin) के लिए, kin setup uninstall --all सभी Kin daemons को भी रोकता है, सटीक लीगेसी इंस्टॉलर PATH ब्लॉक हटाता है, और प्रबंधित इंस्टॉल को पुनरावर्ती रूप से हटाता है (--dry-run इसका पूर्वावलोकन करता है)। एक कस्टम KIN_HOME को कभी भी पुनरावर्ती रूप से नहीं हटाया जाता: पहले ledger-स्कोप्ड uninstall चलाएँ, फिर उस निर्देशिका की समीक्षा करके उसे स्पष्ट रूप से हटाएँ। संशोधित setup-स्वामित्व वाले स्लाइस पूर्ण निष्कासन को रोकते हैं जब तक आप --force नहीं जोड़ते, इसलिए uninstall कभी भी किसी उपयोगकर्ता की संपादित क्लाइंट या शेल कॉन्फ़िगरेशन को चुपचाप अधिलेखित नहीं करता। Windows पर, CLI अपनी लॉक की गई इंस्टॉल निर्देशिका को चालू प्रक्रिया से बाहर निकलते ही हटाने के लिए निर्धारित करता है। Windows जानबूझकर एक निष्क्रिय, केवल-वर्तमान-उपयोगकर्ता sibling authority sidecar बनाए रखता है; उस लॉक पहचान को स्थिर रखने से किसी crash या समवर्ती भविष्य की स्थापना को दो स्वतंत्र mutation authorities बनाने से रोका जा सकता है। CLI और JSON परिणाम इस बनाए रखे गए समन्वय मेटाडेटा का खुलासा करते हैं, न कि शून्य अवशिष्ट बाइट्स का दावा करते हैं।

मैन्युअल स्थापना के लिए, प्रत्येक संग्रह और उसकी .sha256 फ़ाइल https://github.com/firelock-ai/kin/releases/latest/download/ के अंतर्गत प्रकाशित होती है। गतिशील asset नाम हैं kin-macos-aarch64, kin-macos-x86_64, kin-linux-aarch64, kin-linux-x86_64 और kin-windows-x86_64; नवीनतम रिलीज़ पृष्ठ पर दिखाए गए .tar.gz प्रत्यय का उपयोग करें। Windows kin-windows-x86_64.zip भी प्रकाशित करता है, जिसे PowerShell इंस्टॉलर और npm लॉन्चर प्राप्त करते हैं।

npm प्रवेश बिंदु उसी सार्वजनिक रिलीज़ चैनल को हल करता है:

npm install -g @kinlab/kin@latest

एक Homebrew tap उसी रिलीज़ चैनल का अनुसरण करता है:

brew install firelock-ai/kin/kin

tap का formula हस्त-अनुरक्षित होने के बजाय उत्पन्न किया जाता है। इसका संस्करण और इसके प्रति-प्लेटफ़ॉर्म SHA-256 प्रत्येक Kin रिलीज़ से tap रिपॉज़िटरी में update-formula.yml द्वारा पुनर्जनित होते हैं, उस dispatch पर जो रिलीज़ स्वयं भेजती है, साथ ही छह-घंटे का reconcile जो छूटे हुए को स्वयं-ठीक करता है। इसीलिए Homebrew जिस checksum को सत्यापित करता है, वह संग्रह के बगल में प्रकाशित होता है, न कि उसकी अलग से तैयार की गई प्रति। आपने जो स्थापित किया है उसकी पुष्टि kin --version से करें, जैसा आपको किसी भी स्थापना पथ पर करना चाहिए।

Windows पर, PowerShell में irm https://get.kinlab.dev/install.ps1 | iex चलाएँ। नेटिव Windows x86_64 समर्थन प्रारंभिक है। रिपॉज़िटरी प्रवेश कार्य करता है: kin init एक Git रिपॉज़िटरी आयात करता है और graph प्राधिकरण प्रकाशित करता है, और graph, lexical और daemon-समर्थित क्वेरी नेटिव रूप से उत्तर देती हैं। पारदर्शी फ़ाइलसिस्टम प्रोजेक्शन Windows पर नहीं भेजा जाता, और end-to-end इंस्टॉल proof वहाँ MCP या review वर्कफ़्लो को अभी कवर नहीं करता, इसलिए पूर्ण Kin अनुभव के लिए WSL2 अनुशंसित पथ बना हुआ है। Windows इंस्टॉल पथ चुनने से पहले नीचे Platform and maturity पढ़ें।

2. किसी मौजूदा रिपॉज़िटरी को graph सत्य के रूप में प्रवेश दें

cd /path/to/your/repository
kin init .

किसी पता लगाए गए Git रिपॉज़िटरी में, kin init परमाणु रूप से पूर्ण पहुँच योग्य इतिहास, refs, कच्चे objects, सटीक workspace tree और प्रवेश नीति को repository-v6 graph प्राधिकरण में प्रवेश देता है। अप्रतिबद्ध संपादन, staged परिवर्तन या अनट्रैक की गई फ़ाइलों वाला worktree फिर भी प्रवेश देता है: kin init प्रतिबद्ध स्थिति को प्रवेश देता है और खुलासा करता है कि उसने क्या प्रवेश नहीं दिया। यह कभी भी सटीक-HEAD स्नैपशॉट या raw-फ़ाइलसिस्टम semantic पुनर्निर्माण का विकल्प नहीं देता। समर्थित रिपॉज़िटरी-स्थानीय remote URL, refspecs, branch tracking और push डिफ़ॉल्ट Kin की Git सह-अस्तित्व कॉन्फ़िगरेशन में सील होते हैं; असुरक्षित, अस्पष्ट या असमर्थित स्थानांतरण सेटिंग्स प्रकाशन से पहले विफल-बंद (fail closed) होती हैं।

प्रवेश उस इतिहास में प्रत्येक समर्थित entity-source फ़ाइल के लिए semantic entity और relation परत भी व्युत्पन्न करता है, और kin init उन स्थायी, generation-बद्ध गणनाओं की रिपोर्ट करता है जिन्हें उसने प्रतिबद्ध किया। kin status उस रिपॉज़िटरी प्राधिकरण दृश्य की रिपोर्ट करता है; kin graph status अलग से daemon के परिवर्तनीय लाइव क्वेरी ग्राफ़ की रिपोर्ट करता है, जिसमें बाद में व्युत्पन्न संवर्धन शामिल हो सकता है। क्वेरी सतहें graph-स्वामित्व वाले संवर्धन का उपभोग करती हैं जब वह मौजूद होता है और उसकी अनुपस्थिति की रिपोर्ट करती हैं, बजाय खाई को raw फ़ाइल खोज के पीछे छिपाने के।

कौन सी फ़ाइलें entities बनती हैं

"Supported entity-source file" का अर्थ है एक ऐसी फ़ाइल जिसे Kin के किसी भाषा एडेप्टर द्वारा दावा किया जाता है। एडेप्टर रजिस्ट्री ही पूरा समुच्चय है, और रिपॉज़िटरी में हर फ़ाइल उसी के माध्यम से हल होती है:

एक .h हेडर को C++ के रूप में पढ़ा जाता है जब उसकी सामग्री ऐसा कहती है, इसलिए एक C++ प्रोजेक्ट C व्याकरण के कारण namespaces और templates नहीं खोता।

बाकी सब कुछ content के रूप में प्रवेश दिया जाता है और इतिहास व टेक्स्ट के रूप में क्वेरी योग्य रहता है, लेकिन entities और relations में पार्स नहीं किया जाता। इसमें Markdown, HTML और CSS, SQL, YAML, JSON और TOML, शेल स्क्रिप्ट, Objective-C, Scala, Elixir, Dart, Lua, R, Zig, Haskell और Nix शामिल हैं। यदि आपकी भाषा उस सूची में है, तो locate और refs उसमें प्रतीक (symbols) नहीं खोजेंगे।

3. ग्राफ़ से एक वास्तविक प्रश्न पूछें

kin locate "where are webhook retries handled"
kin refs ExactEntityName
kin trace ExactEntityName

ExactEntityName को locate द्वारा लौटाए गए प्रतीक से बदलें। locate किसी इरादे से प्रासंगिक entities ढूँढता है, refs ग्राफ़-स्वामित्व वाले callers/importers और संदर्भ दिखाता है, और trace केंद्रित entity को उसके निकटवर्ती semantic संदर्भ के साथ लौटाता है। एक बार embeddings पूर्ण हो जाने पर, आपका कॉन्फ़िगर किया गया AI एजेंट वेक्टर-समर्थित semantic_locate टूल का उपयोग कर सकता है; get_context_pack, find_references और trace_data_flow ग्राफ़ पड़ोस को सीधे उजागर करते हैं।

प्रवेश semantic entities व्युत्पन्न करता है, उनके vectors नहीं। उन पर स्थानीय वेक्टर समानता जोड़ने के लिए kin embed चलाएँ, और kin graph status से कवरेज की पुष्टि करें।

AI-लिखित परिवर्तन की समीक्षा करें

AI कोड लिखता है। Kin सिद्ध करता है कि क्या बदला।

जिस ब्रांच की आप समीक्षा करना चाहते हैं उस पर kin init चलाएँ ताकि प्रासंगिक Git इतिहास ग्राफ़ में आ जाए, फिर स्पष्ट commit SHA को report-only shadow gate को दें:

kin review shadow "$(git rev-parse main)..$(git rev-parse HEAD)"

परिणाम PASS, NEEDS ATTENTION या WOULD BLOCK होता है, और इसके साथ वह impact आता है जिसे Kin ने ग्राफ़ से व्युत्पन्न किया, उसे ठीक करने के लिए आवश्यक संदर्भ, और दोनों के पीछे के साक्ष्य। Authorship घोषित की जाती है, सत्यापित नहीं। यह कमांड आपके merge को अवरुद्ध नहीं करेगा या graph स्थिति नहीं बदलेगा। यह साक्ष्य किसी मानव या CI नीति को सौंपता है और वहीं रुक जाता है।

Kin का Git से क्या संबंध है

आज Git के बगल में। समय के साथ रिपॉज़िटरी प्राधिकरण। brownfield अपनाने के दौरान, Git एक स्पष्ट import/export अंतर-संचालन सीमा बना रहता है; यह कभी भी Kin runtime क्वेरी का उत्तर नहीं देता या लापता graph सत्य की मरम्मत नहीं करता।

• kin init पूर्ण पहुँच योग्य Git इतिहास और सटीक parent edges आयात करता है। Kin में जानबूझकर कोई आंशिक-इतिहास या केवल-स्नैपशॉट आरंभीकरण मोड नहीं है।
• आयात के बाद, Kin का ग्राफ़ रिपॉज़िटरी पहचान, tree स्थिति, इतिहास, refs और semantic relations का स्वामी होता है। फ़ाइलसिस्टम और Git दृश्य projections हैं।
• kin git export --output ../repo.git एक graph-स्वामित्व वाली प्राधिकरण पीढ़ी से एक नया bare Git projection लिखता है। यह कार्यशील फ़ाइलों या आस-पास के .git/ object store से परामर्श नहीं करता, और किसी मौजूदा या रिपॉज़िटरी-आंतरिक गंतव्य को अस्वीकार करता है। Objects, refs और निर्देशिकाएँ no-replace गंतव्य प्रकाशन स्वीकृत होने से पहले flush होती हैं। Capability-anchored प्रकाशन वर्तमान में Unix होस्ट पर उपलब्ध है; अन्य होस्ट export बनाने से पहले मना कर देते हैं।

यह एक टीम को मौजूदा रिपॉज़िटरी को स्थानांतरित करने देता है, बिना उसके editor, compiler, build system या Git अंतर-संचालन को छोड़े, जबकि Kin प्राधिकृत हो जाता है।

प्लेटफ़ॉर्म और परिपक्वता

मुख्य runtime और फ़ाइलसिस्टम प्रोजेक्शन की समर्थन सीमाएँ अलग-अलग हैं:

पहला अनुक्रमण पूर्ण पहुँच योग्य Git इतिहास पढ़ता है, इसलिए बड़ी या लंबे समय से चली आ रही रिपॉज़िटरी पर kin init को embedding शुरू होने से पहले सेकंड नहीं, बल्कि मिनट लगते हैं। init लौटने के बाद, daemon पृष्ठभूमि में तैयारी जारी रखता है, और बड़ी रिपॉज़िटरी पर पहली एजेंट कॉल का उत्तर देने में उल्लेखनीय रूप से अधिक समय लग सकता है।

सीमित arm64 परीक्षण ने मुख्य graph और lexical पथ को 512 MB पर उपयोग योग्य पाया, लेकिन पूर्ण embedding लगभग 522 MB का मॉडल डाउनलोड करता है और वर्तमान में सुरक्षित परिचालन सीमा के रूप में 2 GB चाहिए; 1 GB एक असुरक्षित किनारा है और 512 MB embedding के दौरान समाप्त हो सकता है। ये देखे गए alpha बाधाएँ हैं, सार्वभौमिक आकार निर्धारण वादे नहीं।

एक सफल kin --version केवल यह स्थापित करता है कि मुख्य बाइनरी चलती है। यह VFS संगतता या एक जीवित graph-समर्थित प्रोजेक्शन स्थापित नहीं करता। किसी समर्थित Unix होस्ट पर, kin setup status, kin-vfs status --workspace . और एक वास्तविक kin-vfs exec --workspace . -- <command> लॉन्च का उपयोग करें। VFS लॉन्चर में एक interposition canary शामिल है और यह रिपोर्ट करता है जब ऑपरेटिंग सिस्टम shim को हटा देता है। kin-vfs README में पूरी सीमा है।

रिलीज़ assets checksum-प्रकाशित होते हैं और रिलीज़ वर्कफ़्लो अपने समर्थित runner मैट्रिक्स में अनाम स्थापना, daemon/MCP, embedding और वास्तविक graph-समर्थित VFS प्रोजेक्शन जाँच चलाता है। वर्कफ़्लो स्वयं सार्वजनिक है: Install Proof। एक हरी (green) रिलीज़ उन सटीक artifacts और वातावरणों को स्थापित करती है; यह दावा नहीं है कि हर वितरण, उपकरण या रिपॉज़िटरी आकार पहले से कवर है।

Proof रुख

प्रकाशित पूर्व-पंजीकृत Multi-SWE-Bench Go proof पैकेज एक पुराने बिल्ड से जुड़ा है, न कि गतिशील नवीनतम रिलीज़ से, और यह व्यापक गति, token-बचत या category-जीत का दावा स्थापित नहीं करता। तुलनात्मक परिणाम स्वतंत्र सत्यापन की प्रतीक्षा में यहाँ रोके गए हैं।

कार्यप्रणाली, कार्य समुच्चय, बिल्ड पहचान और artifacts सार्वजनिक proof पैकेज में पढ़ें। उस मापित दायरे के बाहर के दावों को परिकल्पनाएँ मानें, जब तक उनके पास अपना स्वयं का पुनरुत्पादन योग्य proof न हो।

सीखें और योगदान दें

• त्वरित प्रारंभ और उन्नत कॉन्फ़िगरेशन
• Store का आकार और इसे क्या बढ़ाता है
• MCP टूल संदर्भ
• भाषा समर्थन और प्रत्येक स्तर क्या निकालता है
• Environment variable संदर्भ
• Graph-प्रथम थीसिस
• Write-authority मॉडल और उसकी संक्रमणकालीन स्थिति
• GitHub चर्चाएँ
• बग रिपोर्ट और फ़ीचर अनुरोध
• योगदान मार्गदर्शिका
• निजी सुरक्षा रिपोर्टिंग

लाइसेंस

Apache-2.0.

सॉफ़्टवेयर जो स्वयं को याद रखता है।