تعني مشاركة وكيل مع عميل منح شخص خارجي غرفة واحدة يمكنه من خلالها طرح الأسئلة على وكيل المشروع، ومتابعة عمله، واستلام التسليمات، بينما يظل الوكيل والكود وبيانات اعتمادك على جهازك. عند تطبيقها بشكل صحيح، تكون الصلاحيات للقراءة فقط افتراضيًا، ومحددة بوقت، وقابلة للإلغاء بنقرة واحدة. أما عند تطبيقها بشكل سيئ، فإنها تتحول إلى حساب دخول مشترك.
هذا هو الإعداد الذي نوصي به للوكالات والمستقلين وأي شخص يرغب عميله في «الاطلاع على سير العمل» بوتيرة تفوق ما تسمح به المكالمة الأسبوعية.
The shape
عميل واحد، غرفة واحدة، وكيل واحد، مجلد واحد.
- مجلد واحد. يحتوي
~/clients/acmeعلى مشروع هذا العميل فقط. لا يمكن للوكيل المثبّت عليه رؤية~/clients/betaأو مجلد شركتك أو مفاتيحك. - وكيل واحد، مسمى باسم العميل حتى لا يلتبس على أحد:
acme. - غرفة واحدة، تجمعك بالعميل. وتكون غرفك الأخرى غير مرئية له.
- وضع Plan mode للوكيل، بحيث يُجيب عن الأسئلة ولا يتغير أي شيء على القرص ما لم تقرر أنت خلاف ذلك.
العميل يرى الغرفة؛ الغرفة ترى مجلدًا واحدًا؛ كل شيء آخر على الجهاز بعيد عن المتناول.
What the client can do
- طرح الأسئلة: «ما الذي تغير هذا الأسبوع»، «لماذا يستغرق التصدير دقيقة كاملة»، «أرني design tokens الحالية».
- متابعة عمل الوكيل في الخط الزمني: الملفات التي قرأها، والأوامر التي نفذها، ونهاية المخرجات.
- استلام المخرجات: ملخص، أو مخطط بياني، أو ملف مُصدَّر، أو صورة معاينة.
- إرفاق الملفات: لقطة شاشة لخطأ برمجي، أو جدول بيانات بتعديلات النصوص.
What the client cannot do
- تعديل الكود، في وضع plan mode. إذا قمت بتبديل الوكيل إلى
acceptEditsلمرحلة معينة، فلن تتمكن تعديلاته من إجراء push أو الحذف أو الإنفاق أو المساس ببيانات الاعتماد دون موافقتك. - رؤية الملفات. يرفع daemon أحداث الخط الزمني، وليس شجرة العمل. راجع ما يرفعه الـ daemon.
- رؤية الغرف الأخرى، أو العملاء الآخرين، أو وكلائك الخاصين.
- الموافقة على إجراءاته الخطرة بنفسه؛ إذ يتم توجيهها إليك.
Time-boxing
امنح العميل إذنًا دائمًا طوال مدة المشروع، وضع تذكيرًا بتاريخ الانتهاء. إن إلغاء الإذن، أو إزالة العميل من الغرفة، أو إيقاف daemon يسري فورًا في كل حالة؛ وتُلغى الطلبات المجدولة منه، في حين يكتمل أي إجراء قيد التشغيل ويبقى محفوظًا في السجل. كما يمكن لروابط Invite نفسها أن تحمل تاريخ انتهاء وحدًا أقصى لعدد مرات الاستخدام.
Deliverables and approvals
عندما يطلب العميل من الوكيل إجراء «push the fix»، يصطدم الإجراء بـ push to a shared branch ويتوقف مؤقتًا بانتظارك. وهذا هو السلوك الصحيح: أنت من يقرر متى يُسلَّم العمل. يمكنك منحه Approve، أو رفضه، أو الرد بـ «continue read-only» وتسليمه بنفسك لاحقًا. وتكون الملاحظة التي ترفقها جزءًا من السجل.
What it replaces
Checklist
- أنشئ المجلد
~/clients/<name>واسحب المشروع إليه. - أنشئ وكيلاً مخصصًا له في وضع
plan، وسمِّه باسم العميل. - أنشئ غرفة؛ وأضف الوكيل؛ وأرسل Invite للعميل عبر رابط ينتهي بعد فترة محددة.
- امنح Approve لطلبه الأول؛ ثم امنحه إذن «Allow always» طوال مدة المشروع إذا كنت لا تريده أن ينتظر موافقتك في كل مرة.
- ثبّت daemon كخدمة حتى تظل الغرفة تعمل أثناء ابتعادك عن مكتبك.
- عند انتهاء المشروع: اختر Revoke للإذن وأزل العضو. وسيبقى السجل محفوظًا لك.
Frequently asked questions
هل يحتاج العميل إلى حساب؟ يسجل العميل الدخول عبر رمز يُرسل إلى بريده الإلكتروني أو عبر حساب Google لقبول الدعوة. دون الحاجة إلى تثبيت أي شيء.
هل يمكن لعميلين مشاركة وكيل واحد؟ تجنب ذلك. يضمن تخصيص مجلد لكل عميل إبقاء الحدود مادية وفعلية، وليست مجرد حدود منطقية.
ما التكلفة المترتبة عليّ؟ تُنفَّذ الطلبات عبر اشتراكك الخاص. يُسجَّل الاستخدام لكل شخص على حدة، مما يتيح لك معرفة تكلفة أسئلة العميل ومحاسبته عليها إن أردت.
هل يمكن للعميل رؤية الـ prompts التي أرسلها إلى الوكيل؟ فقط ما يجري داخل غرفته. أما عملك الخاص على قاعدة الكود ذاتها فيكون في غرفة مختلفة مع وكيل آخر.
خصص للمشروع غرفة ودع العميل يطرح أسئلته. ابدأ من هنا.
نُشر في