بديل GitHub Issues عندما تكبر المشاريع على المستودع

فريقك يطلق منتجه من GitHub. طلبات السحب والمراجعة والمَعالم، الدورة كلها تعيش بجوار الكود، ولفترة طويلة كان هذا كافيًا. ثم يأتي أسبوع تجد نفسك فيه أمام لوحة تحمل 14 وسمًا، ثلاثة منها وسوم status: لا يطبّقها إلا نصف الفريق، ولا تستطيع أن تعرف أيًّا من الأخطاء المفتوحة الأحد عشر هو التالي فعلًا، ومن يدير الاجتماع اليومي فتح أربعة تبويبات في المتصفح ليعيد تركيب معنى "قيد التنفيذ". في تلك اللحظة يبدأ الناس بالبحث عن بديل لـ GitHub Issues، ويستحق الأمر أن تحدد بدقة ما تبحث عنه فعلًا، لأن أغلب ما يُرشَّح لك إما مستضيف كود لا تحتاجه، أو متتبّع ثقيل ستندم عليه.

هذه المقالة لفريق يحب GitHub للكود أصلًا ولا ينوي مغادرته. أنت لا تحاول استبدال GitHub، بل تجاوزت Issues كمكان للتخطيط وإعداد التقارير، وتريد متتبّعًا يجلس بجوار المستودع من دون التخلي عن سجل الـ commits الذي تعتمد عليه. الجواب الصريح، وهو ما تدافع عنه بقية المقالة: متتبّع متخصص بجانب مستودعك، لا بديل عن GitHub. ‏Taskfolk لا يستضيف الكود ولا يحاول ذلك. كل الأسعار والحقائق أدناه كما هي في يوليو 2026.

النقطة التي يتوقف عندها GitHub Issues عن الكفاية

‏GitHub Issues ممتاز حقًا فيما بُني له. التذاكر تجلس بجوار الكود، وترتبط بطلبات السحب، والمراجعة تحدث في المكان نفسه، والمَعالم تجمّع العمل، وعلى الخطة Free تحصل على مستودعات عامة وخاصة غير محدودة مع تذاكر ووسوم ومَعالم غير محدودة (كما في يوليو 2026). لمشروع فردي أو مستودع صغير، لا شيء يضاهي انعدام التنقل بين الأدوات.

المشكلة تبدأ عندما يُطلب من Issues أن يتصرف كمتتبّع مشاريع بدل قائمة ملاصقة للكود. ثلاثة أوجاع محددة تظهر، بهذا الترتيب تقريبًا.

أولًا، سير عملك يعيش في الوسوم. تضيف وسم blocked، ووسم in review، وربما needs design. لكن الوسم ليس حالة. لا يمنع شيئًا. لا شيء يمنع تذكرة من حمل done وblocked في الوقت نفسه، ولا شيء يجبر بطاقة على المرور بالمراجعة قبل إغلاقها، ولا شيء من ذلك يغذي تقريرًا، لأن الوسم عند GitHub مجرد علامة، لا حالة يمر بها العمل.

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

ثالثًا، يبقى التخطيط والتقارير ضحلين حتى بعد إضافة Projects. تستطيع بناء لوحة، لكن الأسئلة التي يطرحها اجتماع التخطيط فعلًا (هل نحن على المسار لإنهاء السبرنت؟ ما سرعة هذا الفريق؟ أين يتكدس العمل؟) لا تملك إجابات جاهزة من صميم الأداة.

لا يعني أي من هذا أن GitHub Issues سيئ. يعني أنك طلبت منه أن يكون متتبّعًا، والمتتبّع أداة مختلفة. الحل ليس هجر GitHub، بل وضع متتبّع حقيقي بجواره.

ما أصلحه GitHub Projects، وما بقي ضحلًا

قبل المضي أبعد، من الإنصاف أن نقول الحقيقة كاملة، لأن مقارنة لا تثق بها لا قيمة لها. ‏GitHub Projects خطوة حقيقية للأمام عن Issues الخام، وإن لم تنظر إليه مؤخرًا فعليك ذلك.

كما في يوليو 2026، وبحسب وثائق GitHub، ‏Projects جدول ولوحة وخارطة طريق قابلة للتكييف تتكامل مع تذاكرك وطلبات السحب. تحصل على ثلاثة أنواع من العروض: جدول بأسلوب جداول البيانات، ولوحة كانبان، وخارطة طريق على شكل جدول زمني. وفيه حقل iteration يتيح تخطيط العمل أسبوعًا بأسبوع، بما في ذلك فترات التوقف، وهذه آلية سبرنتات خفيفة ومشروعة. تستطيع إضافة ما يصل إلى 50 حقلًا مخصصًا لكل مشروع من أنواع التاريخ والرقم والاختيار المفرد والنص والـ iteration. وتمنحك Insights مخططات حالية وتاريخية.

رفع GitHub أيضًا سقف حجم المشروع. الحد الأقصى للعناصر في المشروع الواحد ارتفع من 1,200 إلى 50,000، وأُعلن ذلك كمعاينة عامة بتاريخ 2025-02-26 مع طرح تدريجي؛ المشاريع المشمولة بالطرح تعرض مؤشر "Increased items preview". فالشكوى القديمة بأن "Projects ينهار مع باكلوج كبير" تعالَج فعلًا.

لا تدع أحدًا يقول لك إن GitHub بلا تخطيط. فيه تخطيط.

وهنا "لكن" الصادقة: الفجوة في العمق، لا في الغياب.

‏Insights تشحن مخطط "Burn up" افتراضيًا، والوثائق لا تذكر مخطط عمل متبقٍ. إن كانت اجتماعات تخطيطك تدور حول مخطط العمل المتبقي، فهذا فارق حقيقي. الحالة في Projects ما زالت عمليًا حقل اختيار مفرد أو وسمًا. لا يوجد عمود فقري من الفئات تحتها، فلا شيء يفرض أي الانتقالات مشروعة، ولا شيء يضع سقفًا للعمل قيد التنفيذ في كل عمود، ولا شيء يربط العمود بمعنى "مفتوحة" أو "محلولة" تستطيع بقية تقاريرك الاعتماد عليه. الباكلوج المرتّب، والتقارير الأعمق التي يستند إليها الفريق (سرعة الإنجاز، زمن الدورة، التدفق التراكمي)، غير موجودة. ويبقى العمل العابر للمستودعات أو داخل monorepo متعثرًا، لأن المشروع في Projects موجّه نحو عناصر تنتمي غالبًا إلى مستودع واحد.

فإطار بقية المقالة ليس "GitHub لا يستطيع التخطيط"، بل: ‏GitHub Projects يمنحك تخطيطًا واسعًا وضحلًا، والفريق الذي يكبر يريده أعمق في نهاية المطاف.

ما الذي تبحث عنه في بديل GitHub Issues

هذه قائمة مشترٍ، مكتوبة كمعايير لا كعرض ترويجي. إذا كنت تقيّم أي أداة (Taskfolk أو غيره) فقيّمها عليها.

1. احتفظ بأثر الربط بين الـ commit والتذكرة الذي تعتمد عليه. الـ commit المرتبط يجب أن يكون على بعد نقرة واحدة من التذكرة. إن كان نقل تخطيطك خارج Issues يعني فقدان الصلة بين خطأ والـ commit الذي أصلحه، فهذا ثمن باهظ. على الأداة أن تبتلع إشارات الـ commits لديك، لا أن تطلب منك هجرها.

2. حالات حقيقية، لا وسوم. تريد نموذج حالات يقود فعلًا دلالات "مفتوحة" و"محلولة" ويغذي التقارير. الأمثل أن يعني ذلك عمودًا فقريًا ثابتًا من الفئات تعلوه أعمدة مخصصة مسماة، وقواعد انتقال تحدد أي التحركات مشروعة، وحدودًا للعمل قيد التنفيذ لكل عمود.

3. باكلوج مرتّب ولوحة وسبرنتات. باكلوج ترتّبه عمدًا (فتكون الأولوية تسلسلًا صريحًا لا انطباعًا)، ولوحة كانبان للتدفق، وآلية سبرنتات لتأطير الوقت.

4. تقارير تجيب عن أسئلة حقيقية. مخطط العمل المتبقي ومخطط الإنجاز. سرعة الإنجاز. زمن الدورة. معدل الإنجاز. التدفق التراكمي. لا مخطط افتراضي واحد، بل المجموعة التي يمد إليها اجتماع التخطيط يده.

5. يتعامل مع الـ monorepo والعمل العابر للمستودعات. المستودع الواحد يجب أن يستطيع تغذية أكثر من مشروع، والعمل الممتد عبر مستودعات يجب ألا يصارع الأداة.

6. تسعير عادل ودعم للوكلاء. المشاهدون وأصحاب المصلحة يجب ألا يكلفوا مقعدًا كاملًا. وبشكل متزايد، يجب أن يستطيع وكلاء الذكاء الاصطناعي الذين يكتبون كودك الانضمام كأعضاء من دون أن يُحاسَب كل واحد منهم كإنسان.

هذا هو المعيار. بقية المقالة تقيس Taskfolk عليه، وتصارحك بمواطن قصوره.

الاحتفاظ بربط الـ commit بالتذكرة عند نقل التخطيط خارج Issues

أول مخاوف أي شخص ينقل تخطيطه خارج GitHub: إن خططت في مكان آخر، هل أفقد سجل الـ commits؟ الجواب لا، ويستحق الشرح بالتفصيل، لأن الطمأنة الغامضة لا تكفي.

لدى Taskfolk تكامل GitHub رسمي. تربط مستودعًا، فيرسل GitHub ‏webhook عند كل push، ويتحقق Taskfolk منه. فحص التوقيع تحقق HMAC SHA-256 ‏(verifyGithubSignature في src/lib/integrations/github.ts)، فلا تدخل الحمولات المزوّرة. عند كل push يحلل Taskfolk رسائل الـ commits ويستخرج إشارات #KEY-NUM باستخدام التعبير النمطي [A-Z][A-Z0-9]{1,5}-\d+ ‏(extractIssueRefs). ولكل إشارة يجدها يسجل صف commit_refs مقابل التذكرة المطابقة: المستودع، والـ SHA، والرسالة، والرابط، والمؤلف، وطابع وقت الـ commit. الصف فريد على (issueId, repo, sha) فلا يتكرر الـ commit نفسه أبدًا، ولأنه يخزن رابط الـ commit فكل commit مرتبط على بعد نقرة واحدة من التذكرة. هذا هو أثر الربط نفسه بين الـ commit والعمل الذي يمنحك إياه GitHub، محفوظًا في المتتبّع بدلًا منه.

‏#KEY-NUM هو صيغة الإشارة المرجعية الأصلية في Taskfolk، ويعمل في الـ commits وفي التعليقات. اكتب #WEB-42 في رسالة commit فيرتبط. اكتبه في تعليق فيُعرض كشريحة منسقة ويسجَّل صف issue_links من نوع relates_to. تحفظ صادق هنا: الربط التلقائي لـ #KEY-NUM في التعليقات يُحلّ حاليًا مقابل slug المشروع الحالي. عرض الإشارات عبر المشاريع مؤجل، فلا تتوقع بعد أن يحوّل تعليق في مشروع الإشارةَ إلى تذكرة في مشروع آخر إلى شريحة مرتبطة.

يفعل هذا التكامل شيئين آخرين، وكلاهما مفيد تحديدًا للفريق الذي كُتبت له هذه المقالة. أولًا، المستودع الواحد يمكن ربطه بعدة مشاريع Taskfolk في مساحة العمل نفسها. المفتاح الفريد في repo_integrations يتضمن معرّف المشروع، فيستطيع monorepo واحد تغذية عدة مشاريع في آن، وهذه هي الحالة العابرة للمستودعات التي يتعامل معها GitHub Projects بصعوبة. ثانيًا، دفع وسم git يمكنه دفع إصدار Taskfolk للأمام. ادفع refs/tags/v1.4.0 فيطابقه Taskfolk مع نسخة إصدار (resolveAutoShipTag / tagMatchesRelease) ويتقدم الإصدار. دفع الوسم يعني إطلاق الإصدار.

والآن الصراحة الحاسمة، لأن هنا يكذب كثير من عروض "بديل GitHub". هذا استيعاب أحادي الاتجاه. ‏Taskfolk يقرأ الـ commits التي تحمل #KEY-NUM ويقرأ دفعات الوسوم. لا يزامن تذاكرك عائدة إلى GitHub، ولا يعكس طلبات السحب، وهو مقتصر على GitHub اليوم (لا GitLab ولا Bitbucket). يبقى GitHub حيًا للكود وطلبات السحب والمراجعة. ‏Taskfolk هو طبقة التخطيط والتقارير بجواره. إن كنت تأمل مزامنة ثنائية كاملة للتذاكر وطلبات السحب، فهذا ليس ذاك، ومن حقك أن تعرف قبل أن تلتزم.

للخطوات التفصيلية لربط مستودع، اقرأ كيف تربط GitHub.

حالات لها معنى، لا وسوم بديلة عن سير العمل

هذه أكبر ترقية منفردة عن Issues، فتستحق قسمها الخاص.

يستخدم Taskfolk نموذج حالات من مستويين. في الأسفل، سبع فئات حالة ثابتة تحمل الدلالات: backlog وtodo وin_progress وin_review وdone وfailed وcancelled. هذا هو الـ enum في issues.status، وهو ما يقود "مفتوحة"، وطابع وقت الحل، وكل تقرير، وحقل status في الـ API العام. فوق هذه الفئات يجلس جدول أعمدة اللوحة لكل مشروع: أعمدة مسماة وملونة ومرتبة بلا حدود، كل عمود يُسنَد إلى فئة واحدة بالضبط. هذا هو الفصل نفسه الذي يرسمه Jira بين الحالة وفئتها، وهو الفرق بين سير عمل ووسم تتمنى أن يحترمه الجميع.

عمليًا، يبدأ كل مشروع بسبعة أعمدة افتراضية. تضيف عمودًا بزر + في النهاية، ومن قائمة العمود تعيد تسميته أو تلوينه أو تغيّر فئته أو ترتيبه أو تحذفه. تستطيع أيضًا إعادة ترتيب الأعمدة بسحب رأس العمود مباشرة. ولأن كل عمود مثبت على فئة، فالبطاقة الجالسة في عمودك المخصص "Code review" يفهمها النظام كله على أنها in_review: تُحسب مفتوحة، وتظهر صحيحة في زمن الدورة، وتتصرف باتساق في التقارير. الوسم لا يستطيع ذلك أبدًا.

فوق الأعمدة، يدعم Taskfolk قواعد انتقال سير العمل (نموذج allowed_transitions الذي يحدد أي التحركات مشروعة) وحدود العمل قيد التنفيذ لكل عمود. فتستطيع أن تفرض ألا يقفز شيء من todo إلى done مباشرة، وأن تضع سقفًا لعدد البطاقات في "قيد التنفيذ" في آن واحد.

قارن ذلك بـ GitHub. حقل الاختيار المفرد أو الوسم بلا عمود فقري من الفئات، وبلا بوابات انتقال، وبلا سقف WIP. إنه علامة، والعلامات لا رأي لها في كيفية تدفق العمل. لشرح أعمق اقرأ حالات سير العمل المخصصة.

سبرنتات وباكلوج مرتّب والتقارير التي لا يرسمها GitHub

التخطيط والتقارير هما جوهر "تجاوزنا Issues"، فسأتناولهما معًا.

على جانب التخطيط، يمنحك Taskfolk باكلوج مرتّبًا ولوحة وسبرنتات. الباكلوج مرتّب بـ LexoRank، ترتيب معجمي بأساس 62 ‏(rankBetween)، ما يعني أن الأولوية تسلسل متعمد تضعه أنت، لا تخمين تعيد اشتقاقه كل يوم اثنين. اللوحة كانبان بسحب متفائل (مبنية على @dnd-kit) تحفظ status_id البطاقة ورتبتها وأنت تحركها. السبرنتات أطر زمنية حقيقية. أنواع التذاكر تغطي المفردات الرشيقة المسطحة (ملحمة، قصة، مهمة، خطأ، مهمة فرعية)، مع مهام فرعية بعلاقة أب وابن وبطاقة تقدم للمهام الفرعية تُري القصة كم قطع أبناؤها.

ثم التقارير، وهي أحدّ تباين في هذه المقارنة كلها. يشحن Taskfolk طقم تقارير كاملًا (src/lib/analytics/reports.ts مع صفحة تقارير المشروع): سرعة الإنجاز، ومخطط العمل المتبقي، ومخطط الإنجاز، والتدفق التراكمي، وزمن الدورة، ومعدل الإنجاز، وتوزيع الحالات، وتوزيع الأنواع، وعبء العمل، كلها على نوافذ قابلة للاختيار من 7 أيام و30 يومًا و90 يومًا. وتضيف صفحة ملخص المشروع فوق ذلك مخطط عمل متبقٍ للسبرنت ومخططًا دائريًا للحالات.

ضع ذلك بجوار GitHub Projects Insights، الذي يشحن، كما في يوليو 2026، مخطط Burn up افتراضيًا ولا تذكر وثائقه مخطط عمل متبقٍ. إن كان فريقك يدير تخطيط السبرنتات على مخطط العمل المتبقي، أو يسأل "ما سرعة إنجازنا؟" قبل الالتزام بسبرنت، فستحصل على ذلك جاهزًا في Taskfolk وستضطر إلى البناء حول غيابه في GitHub. هذا ليس طعنًا في هندسة GitHub، بل فارق نطاق: ‏Insights طبقة تقارير خفيفة، وتقارير المتتبّع المتخصص أعمق. للجولة الكاملة اقرأ كيف تدير سبرنت وتقارير المشروع ورؤاه. وإن كان ترتيب الباكلوج وجعك العاجل، فمقالة كيف ترتّب أولويات الباكلوج تغطي سير عمل القائمة المرتّبة تحديدًا.

المقارنة الصادقة، بما فيها السعر

هذه المقارنة جنبًا إلى جنب. كل ما يلي مستمد من الحقائق المتحقق منها، وكل الأسعار كما في يوليو 2026.

	GitHub Issues + Projects	Taskfolk
نموذج سير العمل	وسوم / حقول اختيار مفرد	حالات مسنودة بفئات + قواعد انتقال + حدود WIP
الباكلوج	سحب داخل مَعلم، وأولوية بالعين	باكلوج مرتّب (ترتيب LexoRank)
السبرنتات	حقل iteration (أسبوعًا بأسبوع)	سبرنتات + لوحة + باكلوج مرتّب
التقارير	Burn up افتراضيًا، بلا مخطط عمل متبقٍ	سرعة الإنجاز، مخطط العمل المتبقي، مخطط الإنجاز، التدفق التراكمي، زمن الدورة، معدل الإنجاز
الحقول المخصصة	حتى 50 لكل مشروع	حقول مخصصة من 10 أنواع
الحد الأقصى للعناصر	50,000 (في طرح المعاينة)	لا سقف معلن
العمل العابر للمستودعات / monorepo	متعثر	مستودع واحد يغذي عدة مشاريع
وكلاء الذكاء الاصطناعي كأعضاء	غير متاح	أعضاء مجانًا، خارج المقاعد
يستضيف الكود	نعم	لا (يجلس بجوار مستودعك)
السعر	Free بـ $0، ‏Team بـ $4 للمستخدم شهريًا، ‏Enterprise بـ $21 للمستخدم شهريًا	Free بـ $0، ‏Pro بـ $3 لمقعد المنفّذ شهريًا، ‏Business بـ $6 لمقعد المنفّذ شهريًا (المشاهدون مجانًا)

والآن الأسعار نثرًا، لأن الشكل أهم من الرقم المعلّق.

خطط GitHub، كما في يوليو 2026: ‏Free بـ $0 للمستخدم شهريًا، و‏Team بـ $4 للمستخدم شهريًا (نحو $48 للمستخدم سنويًا)، و‏Enterprise بـ $21 للمستخدم شهريًا (نحو $252 للمستخدم سنويًا). أمر يستحق الإبراز: الفئات الثلاث كلها تتضمن القدرات الجوهرية نفسها في Issues و‏Projects، بلا تمييز في الميزات بين الفئات على جدول التسعير. أنت تدفع في الفئات الأعلى مقابل الأمان وضوابط الوصول وإدارة المؤسسات، لا مقابل متتبّع أفضل. و‏GitHub Free كريم على جانب الكود: مستودعات عامة وخاصة غير محدودة مع تذاكر ووسوم ومَعالم غير محدودة، وإن كان لا يشمل ضوابط وصول على مستوى الفريق ولا فروعًا محمية في المستودعات الخاصة.

شكل Taskfolk مختلف. ‏Free بـ $0، و‏Pro بـ $3 لكل مقعد منفّذ شهريًا (نحو $30 سنويًا)، و‏Business بـ $6 لكل مقعد منفّذ شهريًا (نحو $60 سنويًا)، والمشاهدون مجانًا. المهم هو ما يجلس على Free: السبرنتات والجدول الزمني والتكاملات والتقارير والذكاء الاصطناعي متاحة على كل الخطط بما فيها Free. المحجوز للخطط المدفوعة هو الأتمتة والأدوار وSSO والتدقيق. حدود Free هي 128 MB تخزينًا، و5 مشاريع نشطة، و2 من قواعد الأتمتة، و1 MB لكل ملف مرفوع، و25 من رصيد الذكاء الاصطناعي شهريًا. ترفعها Pro إلى 1 GB ومشاريع غير محدودة و20 قاعدة أتمتة و5,000 من الرصيد. وتصل Business إلى 100 GB ومشاريع وقواعد أتمتة غير محدودة و20,000 من الرصيد.

القراءة العملية: مع GitHub تدفع عن كل مستخدم وكل متعاون مستخدم؛ مع Taskfolk لا يكلفك أصحاب المصلحة القارئون شيئًا، ومقاعدك المدفوعة أرخص لكل منفّذ. وإن كانت حجة المقعد الواحد هي ما تصارعه، فمقالة بدائل Jira وسعر المقعد تعرض القضية كاملة.

متى يجدر بك البقاء على GitHub Issues

المقارنة التي تستحق الثقة عليها أن تخبرك متى لا تنتقل. هذا ما يجعلني أبقى على Issues و‏Projects ولا أضيف أداة أخرى.

ابقَ إن كان عملك يُطابق مستودعًا واحدًا بسلاسة والمَعالم تكفي لتجميعه. ابقَ إن كنت لا تدير سبرنتات ولا تحتاج مخطط العمل المتبقي أو سرعة الإنجاز في اجتماعات التخطيط، فحينها يغطيك حقل iteration ومخطط Burn up في GitHub. ابقَ إن أردت كل شيء (الكود وطلبات السحب والمتتبّع) تحت تسجيل دخول واحد وفاتورة واحدة، وكانت الكلفة الذهنية لأداة ثانية لا تستحق. ابقَ إن كان سير عمل قائم على الوسوم يعمل فعلًا بحجم فريقك، وهو ما يحدث كثيرًا في فريق صغير عالي الثقة. وابقَ إن كنت مستثمرًا بعمق في أتمتة GitHub Actions المربوطة بأحداث التذاكر، لأن تلك الأتمتة تعيش حيث تعيش التذاكر.

ولإبقاء الإنصاف في الاتجاهين، هذه حدود الانتقال إلى Taskfolk معادة بوضوح. لا يستضيف الكود، فيبقى GitHub للكود وطلبات السحب والمراجعة. التكامل استيعاب أحادي الاتجاه للـ commits والوسوم، فالتذاكر لا تُزامَن عائدة إلى GitHub وطلبات السحب لا تُعكس. دعم المزودين مقتصر على GitHub اليوم. الربط التلقائي لـ #KEY-NUM في التعليقات يُحلّ مقابل slug المشروع الحالي، فعرض الإشارات عبر المشاريع ليس موجودًا بعد. ولا تُشحن اليوم سوى الإنجليزية والعربية (مع دعم RTL كامل للعربية)، فإن احتجت لغة واجهة أخرى فهذه فجوة.

إن اصطدم أي من ذلك بشرط قاطع عندك، فالتصرف الصحيح هو البقاء حيث أنت. هذه نتيجة أفضل من الانتقال ثم الندم.

ما الذي يتغير عندما ينضم وكلاء البرمجة لديك إلى المتتبّع

هناك شيء واحد يفعله Taskfolk ولا مقابل له في GitHub Issues، ويستحق أن نختم به لأنه وجهة الأدوات كلها.

وكلاء الذكاء الاصطناعي الذين يكتبون كودك يمكنهم أن يكونوا أعضاء حقيقيين في مساحة العمل، ولا يُحاسَبون كمقاعد. العضو الوكيل مُعلَّم (workspace_members.isAgent = 1) ومستبعد من عدّ المقاعد المدفوعة في src/lib/billing/seats.ts، فوكيل البرمجة المتصل يكلف $0. تحت السطح، الوكيل مستخدم وعضو له ملف workspace_agents خاص به ومفتاح API خاص به، وهكذا تُنسَب أفعاله إليه.

يقود الوكلاء المتتبّع عبر السطح نفسه الذي يستخدمه البشر. لدى Taskfolk خادم MCP رسمي مع v1 REST API من أكثر من 180 عملية تغطي المنتج كله، وأدوات MCP مشتقة من سجل OpenAPI نفسه الذي تشتق منه مسارات REST، فالوكيل الذي يتحدث عبر MCP والسكربت الذي يضرب REST يستدعيان العمليات نفسها. الكتابات تمر عبر نقطة اختناق واحدة (updateIssueViaApi)، وصلاحيات الكتابة على مستوى الحقل لكل وكيل (field_policy_json) تُفرض هناك لـ REST و‏MCP والانتقالات على السواء، فتستطيع السماح لوكيل بنقل الحالة من دون إعادة الإسناد، أو بتحرير الوصف من دون لمس الأولوية. جلسات الوكلاء تحمل حالات مراجعة بشرية (معلقة، قيد المراجعة، منجزة)، ويشتق Taskfolk شارة "غير متحقق منه" عند القراءة لأي جلسة أُغلقت من دون أن تترك نشاطًا منسوبًا، فترى متى ادعى وكيل إنجاز عمل لم يظهر له أثر.

هذا هو الاستدعاء الفعلي الذي يجريه وكيل (أو سكربتك الخاص) لفتح تذكرة، على نقطة النهاية الحقيقية. حقول الجسم هي type وtitle وdescription_md وpriority وassignee وlabels.

curl -X POST \
  "https://taskfolk.ai/api/v1/workspaces/acme/projects/WEB/issues" \
  -H "Authorization: Bearer $TASKFOLK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "bug",
    "title": "Login retry loop on expired magic link",
    "description_md": "Repro: open a stale sign-in link twice.\n\nFixed in #WEB-40.",
    "priority": "high",
    "assignee": "[email protected]",
    "labels": ["auth", "regression"]
  }'

const res = await fetch(
  "https://taskfolk.ai/api/v1/workspaces/acme/projects/WEB/issues",
  {
    method: "POST",
    headers: {
      Authorization: "Bearer " + process.env.TASKFOLK_API_KEY,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      type: "bug",
      title: "Login retry loop on expired magic link",
      description_md: "Repro: open a stale sign-in link twice.\n\nFixed in #WEB-40.",
      priority: "high",
      assignee: "[email protected]",
      labels: ["auth", "regression"],
    }),
  },
);
const issue = await res.json();

import os, requests

res = requests.post(
    "https://taskfolk.ai/api/v1/workspaces/acme/projects/WEB/issues",
    headers={"Authorization": f"Bearer {os.environ['TASKFOLK_API_KEY']}"},
    json={
        "type": "bug",
        "title": "Login retry loop on expired magic link",
        "description_md": "Repro: open a stale sign-in link twice.\n\nFixed in #WEB-40.",
        "priority": "high",
        "assignee": "[email protected]",
        "labels": ["auth", "regression"],
    },
)
issue = res.json()

يعود الرد بالتذكرة المنشأة، بمفتاحها الثابت والمُسند إليه محلولًا إلى معرّف مستخدم:

{
  "id": "0192f4c1-6a3b-7c2e-9f10-2b8d4e6a1c33",
  "key": "WEB-42",
  "url": "https://taskfolk.ai/w/acme/p/web/WEB-42",
  "number": 42,
  "type": "bug",
  "title": "Login retry loop on expired magic link",
  "status": "todo",
  "priority": "high",
  "assignee_id": "1c9d2f7a-4b6e-7a10-8c33-9e2b4d6a1f55"
}

اربط ذلك الآن بموضوع المقالة كله. ذلك الوكيل يودع إصلاحه بـ #WEB-42 في الرسالة، فيرسل GitHub الـ push، ويسجل Taskfolk صف commit_ref مقابل WEB-42. فيصطف أثر كود الوكيل ونشاطه في المتتبّع على التذكرة نفسها، تمامًا كما يحدث مع الإنسان. رابط الـ commit بالتذكرة الذي رفضت التخلي عنه هو بالضبط الخيط الذي يخيط عمل الوكيل إلى اللوحة.

إن كنت تحب GitHub للكود أصلًا وتحتاج فقط تخطيطًا وتقارير تكبر مع فريقك، أنشئ مساحة عمل Taskfolk مجانية واربط مستودعك الأول. سيبقى بجوار الكود الذي لن تغادره.