kin v0.5.3

يمكن لوكلاء الذكاء الاصطناعي كتابة تغيير أسرع مما يستطيع الفريق تحديد ما يمسّه، أو ما إذا كان يعكس إصلاحًا سابقًا، أو إلى أي مدى تصل عواقبه. يسجّل Git الملفات وسجل الأسطر. يسجّل Kin البرمجيات نفسها كرسم بياني من الكيانات والعلاقات والتغييرات والأصل، ثم يمنح البشر والوكلاء سلطة دلالية واحدة للاستعلام والمراجعة. ما يمسّه التغيير يظهر قبل دمجه، ويعمل الوكلاء من سياق دقيق بدلاً من إعادة قراءة المستودع.

Kin هو سجلّ النظام الدلالي للبرمجيات المكتوبة بالذكاء الاصطناعي. وهو إصدار ألفا مبكر، قابل للاستخدام اليوم كواجهة سطر أوامر محلية، وخدمة خلفية، وخادم MCP، وسطح مراجعة، وإسقاط نظام ملفات مدعوم برسم بياني. وهو قبل الإصدار 1.0، لذا توقع حواف خشنة وتغييرات كاسرة. راجع أحدث إصدار مستقر والقيود الحالية قبل اعتماده في سير عمل حرج.

شاهدها على مستودع حقيقي

تغيير توقيع من سطر واحد في ripgrep يبدو غير ضار في الفرق. اسأل kin impact عنه، قبل تشغيل أي مترجم، وسيسمّي ما يصل إليه التعديل. تأتي استدعاءات التوقيع المتغيّر أولاً، ثم كل ما تسحبه تلك الاستدعاءات خلفها.

مسجّل مقابل رسم بياني مُعدّ مسبقًا عند commit ripgrep e89fff89ac9af12e8d4ce9d5fd07beb408ca730f. تعديل توقيع من سطر واحد، ويكشف Kin الكيانات التي يؤثر عليها قبل تشغيل المترجم. تم بناء الرسم البياني مسبقًا. لم يعمل أي مترجم. الأوامر الدقيقة: kinlab.ai/proof. دليل التشغيل الخام ليس عامًا بعد، لذا هذه وصفة يمكنك إعادة تشغيلها، وليست أثرًا يمكنك تدقيقه.

يكشف Kin ما يمسّه التغيير. سواء كان التغيير صحيحًا يبقى مع المترجم والاختبارات والمراجعة. يُبنى الرسم البياني مسبقًا بواسطة kin init، وبناؤه هو الجزء المكلف؛ بعد ذلك، تُجاب أسئلة التأثير من حقيقة الرسم البياني، وليس من إعادة قراءة الشجرة.

الحزمة

Kin هو نظام واحد مع عدد قليل من الأسطح العامة الواضحة:

كيف تتناسب الأجزاء

Kin هو سجلّ النظام الدلالي للبرمجيات المكتوبة بالذكاء الاصطناعي، وكل شيء في الخريطة أدناه إما يصل إلى تلك السلطة أو يدعمها. يأتي البشر ووكلاء الذكاء الاصطناعي عبر واجهة سطر الأوامر، أو خادم MCP المدمج، أو إضافة VS Code. جميعها تسأل نفس الخدمة الخلفية، وتجيب الخدمة الخلفية من سلطة الرسم البياني بدلاً من إعادة قراءة الشجرة. يعرض kin-vfs نفس الرسم البياني مرة أخرى عبر استدعاءات نظام ملفات عادية، لذا تستمر المحررات والمترجمات وأنظمة البناء في رؤية الملفات. يجلس Git بجانب الرسم البياني كحدود استيراد وتصدير بدلاً من مسار إجابة، وKinLab هو الطبقة المستضافة فوق نفس السلطة.```mermaid 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-db](https://github.com/firelock-ai/kin-db)** | تخزين الرسم البياني، اللقطات، الفهرسة، البحث النصي، والبحث المتجهي. |
| **[kin-model](https://github.com/firelock-ai/kin-model)** | الأنواع الأساسية ونماذج المجال المشتركة عبر الحزمة التقنية. |
| **[kin-blobs](https://github.com/firelock-ai/kin-blobs)** | تخزين الكائنات الثنائية القابل للعنونة بالمحتوى. |
| **[kin-search](https://github.com/firelock-ai/kin-search)** | بدائيات البحث المعجمي والاسترجاع المرحلي. |
| **[kin-vector](https://github.com/firelock-ai/kin-vector)** | الركيزة المتجهية والبحث عن أقرب جار. |
| **[kin-infer](https://github.com/firelock-ai/kin-infer)** | ركيزة الاستدلال والتضمين. |
| **[kin-lsp](https://github.com/firelock-ai/kin-lsp)** | إثراء خادم اللغة الذي يغذي الطبقة الدلالية. |

هذه طبقات تنفيذ لنظام واحد، وليست منتجات منفصلة يحتاج مستخدم جديد
إلى تجميعها. لا يُثبَّت أيٌّ منها بشكل منفصل.

## المصدر المفتوح ونظام Kin البيئي

جوهر Kin مفتوح المصدر بموجب ترخيص Apache-2.0: [kin](https://github.com/firelock-ai/kin)،
[kin-db](https://github.com/firelock-ai/kin-db)، [kin-vfs](https://github.com/firelock-ai/kin-vfs)،
و[kin-editor](https://github.com/firelock-ai/kin-editor)، بالإضافة إلى المكتبات
الداعمة kin-model وkin-blobs وkin-search وkin-vector وkin-infer وkin-lsp و
kin-actions.

[KinLab](https://kinlab.ai) هو منتج مملوك مبني على هذا النواة المفتوحة:
طبقة الاستضافة التعاونية وطبقة التحكم الموصوفة أعلاه.

ينطبق الحد نفسه على كيفية مشاركة أعمال القياس. [مواصفات
القياس وأداة تحقق مستقلة من الحزمة بدون تبعيات](https://github.com/firelock-ai/kin-bench-spec)
عامة، بحيث يمكن التحقق من أي ادعاء دون الوصول إلى النظام الذي أنتجه.
أما البنية التشغيلية وبنية الإثبات التي تنتج حزم الأدلة المختومة (التنسيق،
وبوابة إثبات الإصدار المثبَّت، وبيئة القياس المستضافة)
فتبقى خاصة في الوقت الحالي. المواصفة وأداة التحقق تُفتح أولًا؛ والبنية التشغيلية
يمكن فتحها لاحقًا.

## أقصر مسار قائم على الرسم البياني

### 1. تثبيت Kin وتكوينه

على macOS أو Linux:```sh
curl -fsSL https://get.kinlab.dev/install | sh
exec "$SHELL" -l
kin setup --intent agent

يقوم المثبّت بحلّ أحدث إصدار مستقر، ويتحقق من مجموع SHA-256 الاختباري المنشور له، ويُثبّت الملفات الثنائية المُدارة تحت ~/.kin، ثم يُطلق الإعداد. تشغيل نيّة agent الصريحة يُهيئ خادم MCP المدمج للعملاء المدعومين المكتشفين. استخدم --intent local لاستخدام سطر الأوامر ونظام الملفات دون إعداد MCP، أو --intent editor لمسار VS Code.

لإزالة عمليات التكامل المُدارة بواسطة الإعداد فقط، شغّل kin setup uninstall. بالنسبة للجذر المُدار الافتراضي (~/.kin)، فإن kin setup uninstall --all يوقف أيضًا جميع خوادم Kin الخلفية، ويزيل كتل مسار PATH القديمة الخاصة بالمثبّت القديم بدقة، ويحذف بشكل متكرر التثبيت المُدار (و--dry-run يعرض معاينة لذلك). لا تتم إزالة KIN_HOME المخصص بشكل متكرر أبدًا: شغّل أولاً إلغاء التثبيت المقيّد بالسجل، ثم راجع وأزل ذلك الدليل بشكل صريح. الشرائح المعدّلة المملوكة للإعداد تمنع الإزالة الكاملة ما لم تُضِف --force، لذا لا يقوم إلغاء التثبيت أبدًا بالكتابة فوق إعدادات العميل أو الغلاف المعدّلة من قبل المستخدم بصمت. على ويندوز، يجدول سطر الأوامر حذف دليل التثبيت المؤمَّن فورًا بعد خروج العملية الجارية. يحتفظ ويندوز عمدًا بملف جانبي واحد خامل للسلطة، خاص بالمستخدم الحالي فقط؛ الحفاظ على استقرار هوية القفل تلك يمنع حدوث تعطل أو تثبيت مستقبلي متزامن من إنشاء سلطتي تعديل مستقلتين. يكشف سطر الأوامر ونتيجة JSON عن بيانات التنسيق المحتفظ بها هذه بدلاً من الادعاء بصفر بايت متبقٍ.

للتثبيت اليدوي، يُنشر كل أرشيف وملف .sha256 الخاص به تحت https://github.com/firelock-ai/kin/releases/latest/download/. أسماء الأصول المتغيرة هي kin-macos-aarch64 وkin-macos-x86_64 وkin-linux-aarch64 وkin-linux-x86_64 وkin-windows-x86_64؛ استخدم لاحقة .tar.gz لأرشيفات macOS وLinux ولاحقة .zip لويندوز، كما هو موضح في صفحة الإصدار الأحدث. ملف zip الخاص بويندوز هو أيضًا ما يجلبه مثبّت PowerShell ومُشغّل npm.

نقطة الدخول في npm تحلّ نفس قناة الإصدار العامة:```sh npm install -g @kinlab/kin@latest

تثبيت عام يتطلب بادئة npm قابلة للكتابة. عندما تكون البادئة مملوكة للجذر ولم تكن أنت الجذر، يرفض npm الأمر مع `EACCES: permission denied, mkdir
'/usr/local/lib/node_modules/@kinlab'` قبل أن يعمل Kin على الإطلاق، وهو الحال المعتاد داخل حاوية يكون مستخدمها الافتراضي غير الجذر. إما أن تستخدم مسار التثبيت الصفري،
`npx -y @kinlab/kin setup --intent agent --no-interactive`، أو انقل البادئة إلى مكان تملكه وضعها في `PATH` الخاص بك:```sh
npm config set prefix ~/.npm-global
export PATH="$HOME/.npm-global/bin:$PATH"   # add this to your shell profile too
npm install -g @kinlab/kin@latest

بادئة المستخدم موجودة في PATH الخاص بقشرتك التفاعلية وليس في أي مكان آخر. البرامج النصية، خطوات CI، docker exec، وعملاء الوكلاء لا يرثونها، لذا أعطِ تلك الأشياء المسار المطلق إلى الملف الثنائي بدلاً من kin المجرد. انظر يعمل مع وكيلك لمعرفة شكل التسجيل.

يتبع Homebrew tap نفس قناة الإصدار:```sh brew install firelock-ai/kin/kin

### 2. اعتماد مستودع موجود كحقيقة للرسم البياني

صيغة الـ tap يتم توليدها بدلاً من صيانتها يدويًا. يتم إعادة توليد إصدارها وقيم SHA-256 الخاصة بكل منصة من كل إصدار من إصدارات Kin عبر `update-formula.yml` في مستودع الـ tap، عند إرسال إرسالية من الإصدار نفسه، مع مزامنة كل ست ساعات تعالج تلقائيًا أي إرسالية فائتة. لهذا السبب فإن المجموع الاختباري الذي يتحقق منه Homebrew هو المنشور بجانب الأرشيف وليس نسخة منفصلة مُدارة بشكل مستقل. تأكد مما قمت بتثبيته باستخدام `kin --version`، كما ينبغي عليك في أي مسار تثبيت.

على Windows، قم بتشغيل `irm https://get.kinlab.dev/install.ps1 | iex` في PowerShell. دعم Windows x86_64 الأصلي في مراحله المبكرة. قبول المستودع يعمل: `kin init` يستورد مستودع Git وينشر سلطة الرسم البياني، كما أن استعلامات الرسم البياني والمعجمية والمدعومة بالخلفية تجيب بشكل أصلي. الإسقاط الشفاف لنظام الملفات غير متوفر على Windows، وإثبات التثبيت الشامل لا يغطي بعد سير عمل MCP أو المراجعة هناك، لذا يظل WSL2 هو المسار الموصى به لتجربة Kin الكاملة.
اقرأ [المنصة والنضج](#platform-and-maturity) أدناه قبل اختيار مسار تثبيت Windows.```sh
cd /path/to/your/repository
kin init .

في مستودع Git مُكتشَف، يقوم kin init بقبول التاريخ الكامل القابل للوصول بشكل ذرّي، والمراجع، والكائنات الخام، وشجرة مساحة العمل الدقيقة، وسياسة القبول في سلطة الرسم البياني repository-v6. مساحة عمل تحتوي على تعديلات غير مُلتزمة، أو تغييرات مُرحّلة، أو ملفات غير مُتتبَّعة لا تزال تُقبل: kin init يقبل الحالة المُلتزمة ويكشف ما لم يقبله. لا يستبدل أبدًا لقطة HEAD دقيقة أو إعادة بناء دلالية لنظام الملفات الخام. عناوين URL البعيدة المدعومة للمستودع المحلي، وrefspecs، وتتبّع الفروع، وافتراضيات الدفع تُختَم في تكوين تعايش Kin مع Git؛ إعدادات النقل غير الآمنة أو الغامضة أو غير المدعومة تفشل بشكل مغلق قبل النشر.

يشتق القبول أيضًا طبقة الكيان والعلاقة الدلالية لكل ملف مصدر كيان مدعوم في ذلك التاريخ، ويُبلِّغ kin init عن العدادات الدائمة المرتبطة بالجيل التي التزم بها. يُبلِّغ kin status عن عرض سلطة المستودع تلك؛ بينما يُبلِّغ kin graph status بشكل منفصل عن الرسم البياني الحي القابل للتغيير للاستعلامات الخاص بالخفي، والذي قد يتضمن إثراءً مشتقًا لاحقًا. تستهلك أسطح الاستعلام الإثراء المملوك للرسم البياني عندما يكون موجودًا وتُبلِّغ عن غيابه بدلاً من إخفاء الفجوة خلف بحث الملفات الخام.

أي الملفات تصبح كيانات

"ملف مصدر كيان مدعوم" يعني ملفًا يدّعيه أحد محوّلات اللغات في Kin. سجل المحوّلات هو المجموعة الكاملة، وكل ملف في مستودع يُحلّ من خلاله:

يُقرأ ملف .h كـ C++ عندما تشير محتوياته إلى ذلك، لذا لا يفقد مشروع C++ مساحات الأسماء والقوالب أمام قواعد لغة C.

كل شيء آخر يُقبل كمحتوى ويبقى قابلًا للاستعلام كتاريخ ونص، لكن لا يُحلَّل إلى كيانات وعلاقات. يشمل ذلك Markdown وHTML وCSS وSQL وYAML وJSON وTOML وسكربتات الصدفة وObjective-C وScala وElixir وDart وLua وR وZig وHaskell وNix. إذا كانت لغتك في تلك القائمة، فلن يجد locate وrefs رموزًا فيها.

3. اطرح على الرسم البياني سؤالًا حقيقيًا```sh

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

استبدل `ExactEntityName` برمز يُرجعه `locate`. يجد `locate` الكيانات ذات الصلة بقصدٍ ما، بينما يُظهر `refs` المُستدعين/المستوردين والمراجع المملوكة للرسم البياني، ويُرجع `trace` الكيان المحوري بالإضافة إلى السياق الدلالي المجاور. بمجرد اكتمال التضمينات، يمكن لوكيل الذكاء الاصطناعي المُهيأ لديك استخدام أداة `semantic_locate` المدعومة بالمتجهات؛ وتكشف `get_context_pack` و`find_references` و`trace_data_flow` عن جوار الرسم البياني مباشرةً.

يستمد القبول الكيانات الدلالية، وليس متجهاتها. شغّل `kin embed` لإضافة تشابه المتجهات المحلي فوقها، وتأكد من التغطية باستخدام `kin graph status`.

## يعمل مع وكيلك

يأتي Kin مع وكيله الخاص، وهو المسار الذي نوصي به للعمل مع الوكلاء. يقود `kin agent run` أي نقطة نهاية متوافقة مع OpenAI، لذا فإن نموذجًا محليًا في LM Studio أو Ollama أو llama.cpp أو vLLM يعمل بنفس العلامات التي يعمل بها النموذج المُستضاف، ويصل إلى الرسم البياني عبر نفس خادم MCP الذي يستخدمه كل عميل آخر.```sh
kin agent run --task "Find where the retry backoff is computed and document it" \
  --model qwen/qwen3.6-35b-a3b --base-url http://localhost:1234/v1

ما الذي يجعل هذا مختلفًا عن توجيه وكيل آخر إلى خادم MCP هو أن القاعدة تُفرض داخل الوكيل بدلاً من استعارتها من طبقة أذونات المورّد. لديه أدوات Kin بالإضافة إلى أداتين محليتين فقط، edit_file و write_file. لا يوجد shell، ولا grep، ولا أداة لقراءة الملفات، لذا لا يمكنه الإجابة على سؤال حول المستودع من بحث ملفات خام، وأي أداة يخترعها تُرفض باسمها. عندما يبلغ Kin أن نتيجة فارغة لا يمكن الوثوق بها، يُخبر الوكيل أن الإجابة غير معروفة ويُعطى الفجوة المسماة بدلاً من استنتاج أن الشيء غير موجود. كل تعديل يعمل داخل معاملة Kin ضمن جلسة Kin، لذا يحمل التغيير مصدرًا يسمي الوكيل. شغّل kin agent doctor --base-url <url> أولاً للتحقق من أن كلا الجزأين يستجيبان. راجع مرجع CLI للسطح الكامل.

العمل مع Claude Code وCodex وCursor وGemini وأي شيء آخر يتحدث MCP يبقى من الدرجة الأولى. kin setup --intent agent يهيئ كل عميل يكتشفه في تمريرة واحدة. هذه هي الأوامر أحادية السطر لكل عميل عندما تفضل تثبيت Kin مباشرة.

Claude Code، من داخل جلسة:``` /plugin marketplace add firelock-ai/kin /plugin install kin@kin

Codex:```sh
codex plugin marketplace add firelock-ai/kin
codex plugin add kin@kin

Gemini CLI:```sh gemini extensions install https://github.com/firelock-ai/kin

Cursor يأخذ رابط تثبيت بنقرة واحدة. الصق هذا في Cursor أو في شريط عنوان متصفحك:```
cursor://anysphere.cursor-deeplink/mcp/install?name=kin&config=eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyIteSIsIkBraW5sYWIva2luLW1jcCJdfQ==

Kiro يأخذ نفس الشيء كرابط ويب: أضف Kin إلى Kiro.

يأخذ Cline الإدخال القياسي أدناه بدلاً من سطر واحد. يقرأ واجهة الأوامر الخاصة به ~/.cline/mcp.json. في امتداد VS Code، افتح لوحة MCP Servers، ثم علامة التبويب Configure، ثم Configure MCP Servers، وأضف الإدخال هناك.

كل عميل آخر يقرأ إعداد MCP قياسي يأخذ هذا الإدخال:```json { "mcpServers": { "kin": { "command": "npx", "args": ["-y", "@kinlab/kin-mcp"] } } }

الغلاف يتطلب Node 20 أو أحدث، وفي أول تشغيل له يقوم بتنزيل
إصدار Kin المطابق، ويتحقق من SHA-256 المنشور له، ويخزّن الملفات الثنائية مؤقتًا لكل
مستخدم. يريد Codex CLI نفس الشيء بصيغة TOML تحت `[mcp_servers.kin]`.

تحذير واحد يستحق التكرار: هذه الأدوات تجيب من الرسم البياني، لذا يجب
اعتماد المستودع باستخدام `kin init .` وتضمينه باستخدام `kin embed` قبل
أن يتمكن `semantic_locate` من ترتيب أي شيء. [llms-install.md](https://github.com/firelock-ai/kin/blob/main/llms-install.md) هو
ذلك المسار الكامل المكتوب بحيث يمكن لوكيل متابعته دون إشراف، من جهاز فارغ إلى
أول استدعاء أداة تم التحقق منه.

## مراجعة تغيير مكتوب بواسطة الذكاء الاصطناعي

**الذكاء الاصطناعي يكتب الكود. Kin يثبت ما تغيّر.**

شغّل `kin init` على الفرع الذي تريد مراجعته بحيث يكون تاريخ Git ذو الصلة في
الرسم البياني، ثم مرّر تجزئات الالتزام الصريحة إلى بوابة الظل المخصصة للتقرير فقط:```sh
kin review shadow "$(git rev-parse main)..$(git rev-parse HEAD)"

النتيجة هي PASS أو NEEDS ATTENTION أو WOULD BLOCK، وتأتي مع تأثير Kin المستمد من الرسم البياني، والسياق اللازم لإصلاحه، والأدلة وراء كليهما. يتم الإعلان عن التأليف، وليس التحقق منه. لن يمنع الأمر دمجك أو يغيّر حالة الرسم البياني. إنه يسلّم الأدلة إلى إنسان أو سياسة CI ويتوقف عند ذلك.

كيف يرتبط Kin بـ Git

بجانب Git اليوم. سلطة المستودع بمرور الوقت. أثناء التبني في المشاريع القائمة (brownfield)، يبقى Git حدودًا صريحة للتوافق عبر الاستيراد/التصدير؛ فهو لا يجيب أبدًا على استعلامات Kin في وقت التشغيل أو يصلح غياب حقيقة الرسم البياني.

• kin init يستورد كامل تاريخ Git القابل للوصول وحواف الأصل الدقيقة. لا يملك Kin عمدًا وضع تهيئة جزئي التاريخ أو لقطات فقط.
• بعد الاستيراد، يملك رسم Kin البياني هوية المستودع، وحالة الشجرة، والتاريخ، والمراجع، والعلاقات الدلالية. أنظمة الملفات وGit هما إسقاطان.
• kin git export --output ../repo.git يكتب إسقاط Git عاريًا جديدًا من جيل سلطة واحد يملكه الرسم البياني. لا يستشير ملفات العمل أو مخزن كائنات .git/ محيطًا، ويرفض وجهة موجودة أو داخل المستودع. يتم مسح الكائنات والمراجع والدلائل قبل الإقرار بنشر الوجهة بدون استبدال. النشر المرتكز على القدرات متاح حاليًا على مضيفات Unix؛ ترفض المضيفات الأخرى قبل إنشاء التصدير.

هذا يتيح لفريق ترحيل مستودع قائم دون التخلي عن محرره، أو مترجمه، أو نظام بنائه، أو توافق Git بينما يصبح Kin هو السلطة.

المنصة والنضج

النواة الأساسية وإسقاط نظام الملفات لهما حدود دعم مختلفة:

الرسم البياني هو السلطة في كل حالة أعلاه. الـ shim، وتركيب NFS، وتركيب FUSE، وWindows ProJFS هي أربع طرق لرؤية تلك الحقيقة كملفات، ويختار Kin بينها بفحص ما يمكن لهذا المضيف تشغيله: تركيب حيث يتوفر واحد، لأن النواة تخدمه ولا يمكن لأي عملية تجريده، مع الـ shim المحقون كبديل توافق على macOS وLinux وProJFS يقود على Windows، حيث لا يوجد shim. kin vfs on يشغّل الخيار المختار، وkin vfs off يوقفه، وkin doctor يحمل صفًا يقول أيها سارٍ وما إذا كان يعمل. حيث يكون الوضع مفقودًا، تطبع Kin السطر الدقيق الذي يثبّته أو يفعّله لمنصتك. docs/projection.md يحتوي الجدول الكامل لكل منصة.

الفهرسة الأولى تقرأ كامل تاريخ Git القابل للوصول، لذا kin init على مستودع كبير أو طويل العمر يستغرق دقائق، وليس ثوانٍ، قبل بدء التضمين. بعد عودة init، تواصل الخدمة الخلفية التحضير في الخلفية، ويمكن أن تستغرق استدعاءات الوكيل الأولى على مستودع كبير وقتًا أطول بشكل ملحوظ للإجابة.

وجد اختبار arm64 المحدود أن الرسم البياني الأساسي والمسار المعجمي قابلان للاستخدام عند 512 ميجابايت، لكن تنزيل التضمين الكامل نموذجًا بحوالي 522 ميجابايت ويحتاج حاليًا 2 جيجابايت كأرضية تشغيل آمنة؛ 1 جيجابايت حافة غير آمنة و512 ميجابايت يمكن أن تنتهي أثناء التضمين. هذه قيود ألفا ملاحظة، وليست وعودًا عالمية بالحجم.

kin --version الناجح يثبت فقط أن الملف الثنائي الأساسي يعمل. لا يثبت توافق VFS أو إسقاطًا حيًا مدعومًا بالرسم البياني. على مضيف Unix مدعوم، استخدم kin vfs status، الذي يفحص كل وضع إسقاط ويطبع ما هو سارٍ فعليًا، ثم kin setup status وإطلاق حقيقي kin-vfs exec --workspace . -- <command>. يتضمن مشغّل VFS كاناري اعتراضًا ويبلغ عندما يجرد نظام التشغيل الـ shim. README kin-vfs يحتوي الحد الكامل.

أصول الإصدار منشورة بفحوصات مجموع اختبارية وسير عمل الإصدار يشغّل التثبيت المجهول، وخدمة الخلفية/MCP، والتضمين، وفحوصات إسقاط VFS الحقيقية المدعومة بالرسم البياني عبر مصفوفة التشغيل المدعومة. سير العمل نفسه عام: إثبات التثبيت. الإصدار الأخضر يثبت تلك الأصول والبيئات المحددة؛ وليس ادعاءً بأن كل توزيع أو أداة أو شكل مستودع مغطى بالفعل.

الأسئلة الشائعة

هل يستبدل Kin Git؟

بجانب Git اليوم. سلطة المستودع بمرور الوقت. يبقى Git حدودًا صريحة للاستيراد/التصدير أثناء التبني في المشاريع القائمة، لذا يمكن للفريق ترحيل مستودع قائم دون التخلي عن محرره أو مترجمه أو نظام بنائه أو توافق Git.

هل تغادر شفرتي جهازي؟

يبقي Kin عمل المستودع المحلي في بيئتك، لذا استيعاب المستودع وتخزين الرسم البياني والاستعلامات المحلية تعمل جميعها هناك. KinLab منتج منفصل يضيف تعاونًا مستضافًا بموجب اتفاقيات وصول صريحة ووصول مبكر.

مع أي وكلاء يعمل؟

العمل مع Claude Code وCodex وCursor وGemini وأي شيء آخر يتحدث MCP يبقى من الدرجة الأولى. kin setup --intent agent يهيئ كل عميل يكتشفه في تمريرة واحدة.

هل يمنع الدمج؟

المراجعة استشارية، لذا تعلّم عن المخاطر دون منع ويبقى قرار الدمج مع فريقك. kin review shadow يسلّم الأدلة إلى إنسان أو سياسة CI ويتوقف عند ذلك.

وضعية الإثبات

حزمة إثبات Multi-SWE-Bench Go المسجلة مسبقًا والمنشورة مثبتة على بناء أقدم، وليس أحدث إصدار متحرك، ولا تثبت ادعاءً واسعًا بالسرعة أو توفير الرموز أو الفوز بالفئة. النتائج المقارنة محجوبة هنا بانتظار تحقق مستقل.

اقرأ المنهجية ومجموعة المهام وهوية البناء والقطع الأثرية في حزمة الإثبات العامة. تعامل مع الادعاءات خارج ذلك النطاق المقاس كفرضيات حتى يكون لها إثباتها القابل للتكرار.

الكتابة

ملاحظات هندسية من بناء Kin، مكتوبة ليتمكن غريب من إعادة استخدامها، منشورة على kinlab.ai/blog مع خلاصة على kinlab.ai/rss.xml.

• الفحص الذي نجح لأنه لم يقس شيئًا
• بحث الشفرة يقول لا شيء يستخدمه. هل يمكنك حذفه؟

تعلّم وساهم

• البدء السريع والتكوين المتقدم
• حجم التخزين وما يحركه
• مرجع أدوات MCP
• دعم اللغات وما يستخرجه كل مستوى
• مرجع متغيرات البيئة
• أطروحة الرسم البياني أولًا
• نموذج سلطة الكتابة وحالته الانتقالية
• مناقشات GitHub
• تقارير الأخطاء وطلبات الميزات
• دليل المساهمة
• الإبلاغ الأمني الخاص

الترخيص

Apache-2.0.

برمجيات تتذكر نفسها.