Adopt a repo کوڈبیس کو 1DesignTool میں لے آتی ہے: ایپ پروجیکٹ کو ایپ کی ملکیت والے worktree پر رجسٹر کرتی ہے — آپ کی app-data ڈائریکٹری کے نیچے 1design/<slug> برانچ — تاکہ ایجنٹ آپ کی اصلی UI کے اندر ڈیزائن کرے بغیر کبھی آپ کے checkout پر لکھے۔ یہ "کوئی چیز ڈیزائن کریں" سے "میری چیز میں ڈیزائن کریں" تک کا پل ہے۔

ایک اپنانا

ہوم اسکرین سے Open folder… ریپو چنتا ہے اور adopt شیٹ کھولتا ہے: یہ فولڈر پڑھتی ہے، پوچھتی ہے کہ اس کے اندر ڈیزائن کرنا ہے یا نہیں، اور Design inside this codebase پر پروجیکٹ کو بطور codebase پروجیکٹ رجسٹر کرتی ہے۔ ایپ worktree بناتی ہے — app-data کے نیچے چیک آؤٹ شدہ 1design/<slug> برانچ — اور پروجیکٹ اس پر کھلتا ہے، آپ کے checkout پر نہیں۔

adopt شیٹ — ریپو کی طرف اشارہ کریں، worktree الگ تھلگی چنیں

آپ کی ریپو انچھوی رہتی ہے: لکھائیاں ایپ کے worktree میں اترتی ہیں، پڑھائیاں اس کے ذریعے آپ کی اصلی فائلوں سے آتی ہیں۔ adopt شیٹ الگ تھلگی کا نوٹ بھی دکھاتی ہے — worktree کیا ہے اور آپ کا checkout ورکنگ کاپی کیوں نہیں۔

worktree ماڈل

کوڈبیس پروجیکٹ 1design/<slug> پر رہتا ہے — وہ برانچ جس کی مالک ایپ ہے، app-data کے نیچے worktree کے طور پر چیک آؤٹ شدہ:

Reads — ایجنٹ worktree کے ذریعے آپ کی اصلی UI دیکھتا ہے
Writes — ٹرن کے diffs برانچ پر اترتے ہیں، آپ کے checkout پر کبھی نہیں
Preview — worktree کا ایپ والا پریویو، یا آپ کا اپنا dev سرور
آپ کا checkout — کبھی نہیں لکھا جاتا؛ host-managed پاتھز (.1design/، skill dirs) .git/info/exclude کے ذریعے چھپتے ہیں، آپ کے .gitignore سے نہیں

پروجیکٹ پر برانچ بار لین دکھاتا ہے — main سے 1design/<slug>، آگے رہنے والے commits کی تعداد، اور وہ فائلیں جنہیں ٹرنز نے بدلا۔

برانچ بار — worktree برانچ، آگے رہنے والے commits، review اور merge ایکشنز

کوڈبیس کے اندر ڈیزائن کرنا

اپنانے کے بعد یہ کسی بھی پروجیکٹ کی طرح سٹیئر ہوتی ہے — مگر بریف آپ کی UI کے بارے میں ہے: "ہیڈر sticky کریں"، "پروفائل کے ساتھ settings اسکرین ڈالیں"۔ ایجنٹ worktree کے ذریعے اصلی فائلوں میں ترمیم کرتا ہے؛ پریویو آپ کے اپنے dev سرور یا ایپ کے پریویو پر چلتی ایپ دکھاتا ہے۔

diff scoped گیٹ

کوڈبیس پروجیکٹس مکمل design kit گیٹ نہیں چلاتے — آپ کی ریپو جنریٹ شدہ آرٹیفیکٹ نہیں، اس لیے اسے ویسے چیک کرنا اُس کوڈ کو بھی flag کرتا جسے ٹرن نے چھوا ہی نہیں۔ اس کے بجائے چیکس diff scoped ہیں: ٹرن کی بدلی ہوئی فائلیں verify ہوتی ہیں (diff پر tells.mjs)، اور برانچ بار کا review ایکشن دکھاتا ہے کہ ٹرن نے بالکل کیا کیا۔

Review اور merge

جب ٹرن کا کام ٹھیک لگے، برانچ بار کا Review changes وہ diff دکھاتا ہے جو ٹرن نے بنایا؛ Copy merge command یا Merge into main برانچ کا کام آپ کی ریپو میں واپس لاتا ہے۔ Discard worktree state پھینک دیتا ہے۔ آپ کے checkout کا main ہی merge ہوتا ہے — worktree سینڈ باکس ہے۔

Build اور Sketch موڈز

کوڈبیس پروجیکٹ لائیو پریویو کے اوپر دو اضافی موڈ رکھتا ہے:

Build mode — چلتی ایپ کی UI میں بصری ترمیم کریں، اور تبدیلیاں واپس کوڈ میں لکھتی ہیں (دیکھیں Build mode)
Sketch mode — .1d sketches جو کمپوننٹس پر نقش ہوتی ہیں (دیکھیں Sketch mode)

Direct mode

worktree ماڈل ڈیفالٹ ہے کیونکہ یہی محفوظ ہے — ایپ app-data کے نیچے اپنی برانچ پر لکھتی ہے، آپ کے checkout پر کبھی نہیں۔ Direct mode — adopt شیٹ پر متبادل — پروجیکٹ کو خود آپ کے checkout کی طرف کرتا ہے؛ ایجنٹ اصلی فائلوں میں درجے میں ترمیم کرتا ہے۔ یہ تیز ہے مگر کام آپ کی ورکنگ کاپی پر اترتا ہے، اسی لیے worktree ڈیفالٹ وجہ سے موجود ہے۔

یہ کن چیزوں میں اچھا ہے

اپنی اصلی ایپ کے اندر ڈیزائن — وہ اسکرین جو پہلے سے موجود ہے، دوبارہ اسٹائل شدہ
فیچر کا کام — نئی اسکرین یا فلو، درجے میں
UI پاسز — پوری ایپ کا بصری پاس، diff شدہ
کوڈبیس پر آن بورڈنگ — ایجنٹ اسی ریپو کو پڑھتا ہے جس میں رہنا ہے

الگ تھلگی کا نوٹ

worktree اس لیے موجود ہے کہ ایجنٹ کا کام آپ کے checkout کو merge تک نہ چھو سکے — رجسٹر شدہ پروجیکٹ روٹ ایپ کی برانچ ہے، reads اور writes اسی سے گزرتے ہیں، اور پروجیکٹ کو جن host-managed فائلوں کی ضرورت ہے وہ .git/info/exclude کے ذریعے چھپتی ہیں تاکہ آپ کا git status صاف رہے۔ لاگت ایک قدم ہے: جب کام ٹھیک ہو، آپ برانچ merge کرتے ہیں۔

مشورہ: merge صاف ہونے تک worktree رکھیں — کام کی تصدیق سے پہلے برانچ مٹانا diff کی قیمت ہے۔ merge بٹن اسے ایک ایکشن بنا دیتا ہے؛ کلک کرنے سے پہلے review کریں۔

کوڈ ریپو اپنائیں