حل المشكلات

aipager doctor

يشغّل كل الفحوص أدناه بالترتيب ويطبع تلميح الإصلاح المعتمد لكل فشل. المصدر: aipager/doctor.py.

«Another aipager daemon already owns the socket»#

لا يمكن لنسختين من aipager مشاركة مقبس تحكم واحد. هذا الخطأ يعني أن aipager ما زال يعمل ويجيب عليه (المقبس هو ‎$XDG_RUNTIME_DIR/aipager.sock، أو ‎/tmp/aipager.sock عندما لا يكون ‎$XDG_RUNTIME_DIR مضبوطًا). ملف مقبس متبقٍّ من aipager تعطّل ليس مشكلة: البدء التالي يحذفه وينشئ مقبسًا جديدًا. يلزم أولًا إيقاف aipager الجاري:

aipager service stop          # إن كان يعمل كخدمة
pkill -f 'aipager start'      # وإلا

إذا فات فحصَ المقبس، يرفض aipager start مع ذلك بالرسالة aipager is already running (pid=N) ويذكر ملف القفل (‎~/.local/share/aipager/daemon.lock): تُوقف تلك العملية بالطريقة نفسها.

بوت Telegram لا يستجيب#

1. ‏aipager status: إذا كان سطر aipager يقول not running، يلزم تشغيله.
2. ‏aipager doctor: يتصل الفحصان token_valid وchat_reachable بواجهة Telegram البرمجية من البداية إلى النهاية ويظهران الخطأ بالضبط.
3. دردشة خاطئة: تشغيل aipager config واختيار Test bot reachability. لإصلاح دردشة خاصة خاطئة، تُضاف الصحيحة عبر Add a DM scope (يُنظر إيجاد المعرّفات)، ثم تُحذف الخاطئة من Edit a scope.
4. البوت لم يتلقَّ ‎/start أبدًا: فتح البوت في Telegram والضغط على Start مرة واحدة.

بطاقات العمل أصبحت أبطأ#

يسمح Telegram بنحو رسالة واحدة في الثانية لكل دردشة (و٢٠ رسالة في الدقيقة للمجموعة). كل رسالة وكل تعديل يُحسب. يعطي aipager كل دردشة ميزانيتها الخاصة بنحو طلب واحد في الثانية، مع هامش صغير للدفعات، وبطاقات العمل في تلك الدردشة تتشارك فيها. ومؤشر «يكتب…» داخل هذه الميزانية أيضًا، بوصفه أقل ما ترسله الدردشة أهمية (يُنظر «فقاعة الكتابة» أدناه).

حصة الفقاعة تُحجز أولًا (طلب واحد كل ٤٫٥ ثانية ما دامت أقدم مهمة جارية في الدردشة لم تبلغ عشر دقائق، وأقل كلما طالت؛ يُنظر «فقاعة الكتابة»)، وتتقاسم البطاقات الباقي. لذا تتحدّث بطاقة واحدة في دردشة خاصة كل ٤٫٨ ثانية تقريبًا؛ ومع جلستين تعملان في الدردشة نفسها، كل بطاقة كل ٩٫٧ ثانية تقريبًا؛ ومع ثلاث، كل ١٤٫٥ ثانية تقريبًا. البطاقة الأبطأ هي الميزانية تؤدي عملها، لا خلل. الإجابات والردود واستجابات الأزرار لا تُبطَّأ أبدًا لإفساح المجال لبطاقة: لها رصيد محجوز، وتعديل البطاقة الذي لا يجد رصيدًا يُتخطى ببساطة ويُعاد في الدورة التالية بدل أن يصطف أمام إجابتك.

في المجموعة الحد ٢٠ طلبًا في الدقيقة مهما كان عدد الجلسات فيها، والفقاعة وحدها كانت ستستهلك ثلثيه. تحتفظ بطاقات المجموعة معًا بتحديث واحد كل ١٠ ثوانٍ (١١ ثانية لبطاقة واحدة)، وتأخذ الفقاعة الباقي: لذا قد تختفي في المجموعة ثانية أو ثانيتين بين حين وآخر.

لتسريع البطاقات: تشغيل جلسات متزامنة أقل في كل دردشة، أو إعطاء الجلسات الأكثر انشغالًا دردشة خاصة بها (aipager config). ويمكن أيضًا ضبط STREAM_EDIT_INTERVAL (الافتراضي 1.2، الإيقاع أثناء تدفق النص في البطاقة) وBUSY_EDIT_INTERVAL (الافتراضي 3.0، حين تكون هادئة)، كمتغيرات بيئة لـ aipager (يُنظر الإعدادات من البيئة). ضبط أي منهما أقل من الحد الأدنى للدردشة لا يضر ولا يغيّر شيئًا: الحد الأدنى هو الغالب، وهذا بالضبط ما يُبقي الدردشة تحت حد Telegram مهما كانت القيمة.

بطاقة المهمة الطويلة تتحدّث بوتيرة أقل#

الإيقاع أعلاه للدقيقتين الأوليين من المهمة. بعد ذلك تتباطأ البطاقة كلما طالت المهمة، ومن الدقيقة العاشرة تتحرك ساعتها بخطوات من ٣٠ ثانية، متوافقة مع التحديث، فلا تبدو معلّقة أبدًا:

تُقرَّب الساعة نزولًا إلى خطوة الـ ٣٠ ثانية، والتحديثات تفصل بينها ٣٠ ثانية على الأقل، وأحيانًا أكثر بقليل. لذا تقفز البطاقة خطوة بين حين وآخر: تحديث عند ٢٣ دقيقة و٢٩ ثانية يعرض ٢٣:٠٠، وإذا جاء التالي عند ٢٤ دقيقة وثانية واحدة فإنه يعرض ٢٤:٠٠، فتُتخطى ٢٣:٣٠.

سطر أداة جديد أو جملة جديدة ينتظر التحديث التالي؛ أما تغيّر الحالة (انتقال الجلسة من العمل إلى انتظار وكيل في الخلفية، والعكس) فيظهر فورًا، مرة كل ١٠ ثوانٍ على الأكثر. أسطر الوكلاء الحية وسطر الانتظار تتبع الخطوات نفسها. وتعرض البطاقة المنتهية مدة المهمة بالثواني الحقيقية (٢٣:١٧).

هذا ما يمنع مهمة من أربع ساعات من تعديل رسالة واحدة آلاف المرات: في ٢٠٢٦-٠٩-٢٣ فعلت بطاقة ذلك بالضبط، وحُظرت الدردشة سبع ساعات. للإبقاء على الإيقاع السريع طوال المهمة، يُوقف ‎/settings ← ⏱ تحديث البطاقة في المهام الطويلة (للدردشة، أو لكل جلسة من Mini App أو من 👤 إعدادات كل جلسة).

فقاعة الكتابة#

ترسل فقاعة «يكتب…» حلقةٌ واحدة لكل دردشة، مهما كان عدد الجلسات العاملة فيها (الفقاعة للدردشة كلها في كل تطبيقات Telegram)، كل TYPING_INDICATOR_INTERVAL ثانية (الافتراضي ٤٫٥: يمسح Telegram حالة الكتابة بعد ٥؛ و0 يوقف الفقاعة). وتُحسب في ميزانية الدردشة بوصفها أقل ما ترسله الدردشة أهمية:

• تتباطأ كلما طالت المهمة، بحسب عمر أقدم مهمة جارية في الدردشة: كل ٤٫٥ ثانية في الدقائق العشر الأولى (فقاعة ثابتة)، ثم كل ١٥ ثانية؛ يعرضها Telegram ٥ ثوانٍ، فتومض فقاعة المهمة القديمة بدل أن تبقى مضاءة. عند ٤٫٥ ثانية وحدها تبلغ ٨٠٠ طلب في الساعة، وكان الحد الساعي (أدناه) سيوقفها فترات طويلة؛ وإيقاف ⏱ تحديث البطاقة في المهام الطويلة يُبقيها عند ٤٫٥ ثانية؛
• تظهر منذ بداية كل مهمة؛ والبطاقة الحديثة تتحدّث أبطأ بقليل لإفساح المجال: حصة الفقاعة تُحجز قبل أن تتقاسم البطاقات الباقي (أعلاه)، فلا يتجاوزان معًا حدود الدردشة أبدًا؛
• لا تأخذ أبدًا رصيدًا يحتاجه تعديل بطاقة: الفقاعة المستحقة بعد تعديل بطاقة مباشرة تنتظر نصف ثانية (TYPING_RETRY_WAKE) ثم تحاول مجددًا، فتتأخر ثانية أو ثانيتين على الأكثر، ولا تضيع أبدًا؛
• هي أول ما يُترك حين يرتفع حجم الدردشة في الساعة (أدناه)؛
• خطأ 429 على الفقاعة نفسها يوقف الفقاعة وحدها، طوال المدة التي طلبها Telegram (تستمر البطاقات)، لكنه يبدأ فترة التحذير ذات الساعات الست للدردشة (يُحدّ الإيقاع بـ ٠٫٥ طلب في الثانية، فتتباطأ البطاقات أيضًا)؛
• الحظر على الفقاعة (retry_after يتجاوز الحد أدناه) يوقف الإرسال إلى الدردشة تمامًا كالحظر على أي طلب آخر: لا شيء يُرسل إليها بعد ذلك، وتُحتجز إجابة المهمة وتُسلَّم حين يُرفع الحظر.

كانت مجانية سابقًا (حلقة لكل جلسة عاملة، خارج أي ميزانية)، إلى أن أرسلتها جلستان في دردشة خاصة واحدة نحو ٥٤٠٠ مرة في ثلاث ساعات في ٢٠٢٦-٠٩-٢٣، فحدّ Telegram سرعة الفقاعة نفسها.

البوت أصبح أبطأ: حد السرعة (429)#

إذا حدّ Telegram سرعة دردشة رغم ذلك، فإنه يجيب عن طلب واحد بـ 429 مع retry_after لبضع ثوانٍ. يتوقف aipager عن مراسلة تلك الدردشة تلك المدة بالضبط، ثم يعيد الإرسال المؤجل الوحيد، ويضاعف فاصل تحديث بطاقات تلك الدردشة (حتى ×٨). كل دقيقة هادئة تنصّفه حتى يعود إلى طبيعته.

ما يظهر لك:

• يعرض aipager status (وسطر aipager daemon في aipager doctor) Telegram flood backoff ×4 (chat …), last 429 12 s ago.
• سطر واحد بالضبط في aipager logs، دون traceback:‏ flood: chat … 429 retry_after=5s → cadence ×2.
• لا شيء يُوقف، ولا تضيع أي إجابة: تُؤجَّل، ولا تُترك.
• ينخفض معدل الإرسال الذي اكتسبته الدردشة إلى النصف، وتدخل الدردشة فترة تحذير من ست ساعات (FLOOD_WARNING_HOURS): لا يمكن أن يرتفع معدلها فوق ٠٫٥ طلب في الثانية (FLOOD_WARNED_CEILING)، ويعود إلى الارتفاع ببطء. يعرض aipager status ذلك: Telegram chat 123: rate 0.25/s (ceiling 0.50/s), 212/1200 calls in the last hour (as of 18s ago), 7/30 in the last minute - warning regime, 5h 52m left.

لا شيء مطلوب منك. يزول من تلقاء نفسه. يختفي سطر التباطؤ بعد أن تهدأ الدردشة دقيقة أو اثنتين؛ ويرتفع المعدل ٠٫١ طلب في الثانية عن كل فترة هادئة (دقيقة عادةً، و٣٦ دقيقة أثناء فترة التحذير)، ويعود السقف الكامل حين تنتهي الفترة. يُبقي aipager doctor سطر aipager أخضر طوال ذلك: الدردشة التي يُبطَّأ الإرسال إليها تشغيل طبيعي. (كان خطأ 429 يُنسى سابقًا بعد نحو خمس دقائق. التحذير الوحيد من Telegram قبل حظر ٢٠٢٦-٠٩-٢٣ جاء قبله بثلاث ساعات و٢٣ دقيقة، وعادت الدردشة إلى السرعة الكاملة بعده بدقائق.)

الميزانية الساعية#

لكل دردشة أيضًا ساعة متحركة: FLOOD_HOURLY_MAX (١٢٠٠) طلب على الأكثر في أي ٦٠ دقيقة، فقاعات الكتابة وتعديلات البطاقات والإجابات معًا؛ ولا يُستثنى إلا التفاعلات (reactions). آخر ١٢٠ (FLOOD_HOURLY_ESSENTIAL_RESERVE) محجوزة للإجابات والردود والطلبات:

• عند ٨١٠ طلبات في الساعة تتوقف فقاعة الكتابة مؤقتًا (وتعود تحت ٦٤٨)؛
• عند ١٠٨٠ تدخل الدردشة الوضع الأدنى (أدناه) حتى تنخفض الساعة إلى ٨٦٤؛
• لا تُرفض الإجابات أبدًا بسبب الحد الساعي؛ وإذا تجاوزت ١٢٠٠ يومًا ما، يذكر السجل ذلك مرة في الساعة.

يعرض aipager status طلبات الدردشة في الساعة الأخيرة مقابل ميزانيتها. يأتي الرقم من ملف الحالة، الذي يعيد aipager كتابته مرة في الدقيقة على الأكثر ما دامت الطلبات جارية، لذا يُذكر معه عمره. جلستان تعملان وترسلان إلى دردشة خاصة واحدة لساعات تبقيان أدنى من الميزانية بكثير (حادثة ٢٠٢٦-٠٩-٢٣ عند إعادة تشغيلها: نحو ٩٠٠ طلب في أكثر الساعات انشغالًا، مقابل نحو ٣٤٠٠ في النموذج للعمل نفسه دون الميزانية).

المعدل المكتسب، ولماذا قد تكون بطاقاتك أبطأ من قبل#

منذ 0.7.13 يُتعلَّم معدل الإرسال المستمر لكل دردشة بدل أن يُفترض. لا ينشر Telegram الحد الذي يسري فعلًا على بوتك (يعتمد على تاريخ حسابك القريب)، لذا يبدأ aipager كل دردشة عند ٠٫٥ طلب في الثانية، ويضيف ٠٫١ عن كل دقيقة هادئة حتى سقف ١ في الثانية، وينصّفه عند 429، ويخفضه إلى ٠٫٠٥ بعد الحظر. وهكذا يُدار البوت الذي حُظر للتو بحذر أكبر بكثير من بوت لم يُحظر، ويستعيد سرعته خلال الساعات التالية.

إذا انخفض معدل دردشة تحت ٠٫٢ طلب في الثانية، أو نفدت حصة البطاقات والفقاعات من ميزانيتها الساعية، تدخل الوضع الأدنى: تتوقف حركة بطاقات العمل وتعرض سطرًا ثابتًا واحدًا ⏳ x1 · تعمل (تحديث البطاقة متوقف مؤقتًا)، وتتوقف فقاعة الكتابة، ويعرض شريط الحالة المثبّت ⏸ تحديث البطاقات متوقف مؤقتًا (حد Telegram في الساعة) (أو (حدود Telegram) حين يكون المعدل هو ما أدخل الدردشة فيه) ولا يتغير غير ذلك حتى يزول. تستمر الإجابات والردود وطلبات الإذن في الوصول: وهذا هو المقصود. البطاقة نحو ٩٥٪ مما يرسله هذا البوت والإجابة نحو ٥٪، لذا تحت الضغط يتخلى عن المظهر لا عن العمل. يعرض aipager doctor الوضع الأدنى كتحذير حتى لا تُحسب البطاقة المتوقفة مؤقتًا معطّلة؛ ويزول وحده حين يتعافى المعدل.

البوت صامت: حظر Telegram (flood control)#

قيمة retry_after التي تتجاوز TELEGRAM_MAX_RETRY_AFTER (الافتراضي ٩٠ ثانية) ليست حد سرعة، بل حظر، وقد يستمر ساعات. من الدردشة يبدو كأن البوت مات: الرسائل ما زالت تصل إلى Claude، والجلسات ما زالت تعمل، لكن لا إجابة تعود.

ما يظهر لك:

• يعرض aipager status (وسطر aipager daemon في aipager doctor) Telegram flood-muted until HH:MM (chat …).
• سطر واحد في aipager logs:‏ Telegram flood control — chat … muted for Ns (until HH:MM) …‎، ثم صمت لتلك الدردشة. ولاحقًا سطر واحد flood mute on chat … lifted.
• يعرض aipager status أيضًا حالة الدردشة كاملة: Telegram chat 123: rate 0.05/s (ceiling 0.50/s), 431/600 calls in the last hour (as of 12s ago) - MINIMAL MODE, card updates paused - flood-muted until 09:41 - warning regime, 5h 59m left (1 ban(s) in the last 7 days).

يوقف aipager الإرسال إلى الدردشة طوال المدة التي طلبها Telegram بالضبط ولا يرسل إليها أي طلب من أي نوع: لا إجابات، ولا تعديلات لبطاقات العمل، ولا مرفقات، ولا تفاعلات، ولا مؤشرات كتابة، ولا إشعارات الضغط على الأزرار، ولا الردود التي كانت أوامرك ستنتجها. كل واحد منها سيكون مخالفة جديدة تطيل الحظر؛ فطلب واحد أثناء حظر قائم هو ما حوّل حظرًا من ٢١ دقيقة إلى ٩٫٥ ساعة في ٢٠٢٦-٠٩-١٥. لذا فالأمر المكتوب أثناء الحظر لا يتلقى أي رد، والضغط على زر لا يُؤكَّد أيضًا: حتى 0.7.12 كان إشعار الزر ما زال يُرسل، على افتراض أن Telegram يحسبه منفصلًا. يفعل ذلك في ضبط الإيقاع؛ ولا يفعله في الحظر. الدردشات الأخرى لا تتأثر.

مراسلة البوت أثناء الحظر آمنة، ولا يضيع شيء. لا شيء مما يُفعل في الدردشة يجعل البوت يتصل بـ Telegram ما دام الإرسال إليها موقوفًا، فلا يمكنه إطالة الحظر:

• الرسالة المرسلة (نص، أو رسالة صوتية، أو ملف، أو قالب سريع) تصل إلى Claude وتعمل عليها الجلسة. تُحتجز بطاقة عملها ولا تُترك: إذا كانت المهمة ما زالت جارية حين يُرفع الحظر، تظهر البطاقة عندها. يترك الحظر الدردشة في الوضع الأدنى بعده لبعض الوقت، لذا قد تتأخر البطاقة دقائق بعد الحظر نفسه. وإذا انتهت المهمة أثناء الحظر، تصلك إجابتها دون بطاقة.
• 🔄 إعادة المحاولة لا يفعل شيئًا أثناء الحظر. لا تُعاد الرسالة ويبقى الزر، فيمكن الضغط عليه مرة أخرى بعد رفع الحظر. حتى 0.7.14 (ضمنًا) كانت الرسالة تذهب إلى Claude بينما تبقى رسالة الخطأ وزرها، فكانت الضغطة الثانية ترسلها مرة أخرى.
• لوحة المفاتيح الرئيسية تُحتجز أيضًا، ومنها التي ترسلها إعادة التشغيل (حتى 0.7.14 (ضمنًا) كانت تضيع حتى يحدّثها شيء آخر). تُرسل بعد رفع الحظر.

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

الإجابات لا تضيع. الإجابة التي تنتج أثناء إيقاف الإرسال إلى الدردشة تُحتجز وتُسلَّم بعد رفع الحظر بثوانٍ، وسطرها الأول ⏳ وصلت متأخرة: احتُجزت ٤٢ دقيقة بسبب حدود Telegram. لا حاجة إلى السؤال مرة أخرى، وإن سألت مرة أخرى فستصل الإجابتان، الأقدم أولًا: الحظر الذي يدوم ساعات يمتد عبر عدة مهام وإجابة كل منها لك. (الإجابات المحتجزة تعيش في الذاكرة: إذا أُعيد تشغيل aipager وبعضها ينتظر، تضيع؛ ويذكر سجل الإيقاف عددها. تحتجز الدردشة ٢٠ على الأكثر، ولا شيء أقدم من ٢٤ ساعة؛ وكل ما يُترك لأي من السببين يظهر تحذيرًا في السجل يذكر ما هو.)

الحظر يجعل الدردشة أبطأ بعده، لا أسرع. لحظة تسجيل الحظر، ينخفض معدل الدردشة المتعلَّم إلى الحد الأدنى ويُحسب الحظر؛ وساعات الإيقاف لا تكسب شيئًا، والصعود يبدأ من جديد لحظة رفع الحظر، ولمدة سبعة أيام (FLOOD_BAN_MEMORY_DAYS) يُقسم سقف معدل الدردشة وميزانيتها الساعية على واحد زائد عدد مرات الحظر في ذلك الأسبوع: حظر واحد ينصّف الاثنين، وحظران يقسمانهما على ثلاثة. يعرض aipager status كل ذلك. (كانت هذه الذاكرة ٢٤ ساعة فقط ولا تنصّف إلا السقف؛ دردشة حُظرت في ٢٠٢٦-٠٩-١٩ عادت إلى السرعة الكاملة، وحُظرت سبع ساعات، في ٢٠٢٦-٠٩-٢٣.) خمس مرات حظر أو أكثر في أسبوع تُبقي الدردشة في الوضع الأدنى حتى تنتهي صلاحيتها: تستمر الإجابات، وتبقى البطاقات متوقفة.

ما يجب تجنبه:

• إعادة تشغيل aipager «لإصلاح» الأمر. يزول الإيقاف وحده في الوقت المعروض. منذ 0.7.13 لم تعد إعادة التشغيل تنسى الحظر (موعد انتهائه، ومعدل الدردشة المكتسب، وتاريخ حظرها تُحفظ في ‎~/.claude/aipager-flood-state.json وتُستعاد عند البدء، وكذلك طلبات الدردشة في الساعة الأخيرة وفترة التحذير)، لذا لم تعد إعادة التشغيل تطيله أيضًا. لكنها ترمي كل إجابة ما زالت محتجزة، ولا تصلح شيئًا.
• خفض TELEGRAM_MAX_RETRY_AFTER تحت الافتراضي ٩٠ ثانية أملًا في إعادة المحاولة أسرع: كل ما يتجاوز ذلك الحد حظر، لا حد سرعة.

للتجنب: تشغيل جلسات متزامنة أقل في كل دردشة، أو إعطاء الجلسات الأكثر انشغالًا دردشة خاصة بها (aipager config).

جلسة اختفت من شريط الحالة المثبّت (حالتها GONE)#

خرجت عملية dtach الخاصة بتلك الجلسة (إعادة تشغيل الكمبيوتر، أو pkill claude، أو كتابة أحدهم exit في جلسة dtach المتصلة). يمكن إنشاؤها من جديد: محادثتها ما زالت في مجلدها ‎~/.claude/projects/...‎.

أسهل طريق هو ‎/resume <label>‎ في Telegram (أو ‎/resume وحده لقائمة اختيار): يعيد تشغيل الجلسة ويكمل المحادثة. ومن سطر الأوامر:

aipager resume <label>             # الشيء نفسه من الطرفية
aipager session <label>            # أو جلسة جديدة، دون سجل
aipager session <label> --continue # dtach جديد، وآخر محادثة في المجلد

طلب إذن بلا أخبار منذ ٥ دقائق#

إذا كانت جلسة تنتظر طلب إذن أو سؤالًا ولم يرسل Claude Code أي خبر خلال ٥ دقائق، يقرأ aipager المحادثة المحفوظة للجلسة. ولا يُحسب إلا خبر Claude نفسه وخبر الوكيل الذي طلب: وكيل في الخلفية يواصل العمل لا يمنع هذا الفحص من أن يجري. ولا يتوقف aipager عن انتظار الطلب ويعدّ الجلسة عاملة من جديد إلا إذا أظهرت المحادثة أن الطلب انتهى (أُجيب عنه في الطرفية وضاع خبر ذلك). وإلا يبقى الطلب مفتوحًا مهما طال الوقت: تظل البطاقة والشريط المثبّت يقولان إن الجلسة بحاجة إلى إجابتك، ولا تُرسل ملاحظة «لا يزال يعمل»، وتُحتجز رسائلك حتى تأتي إجابتك (يُنظر النص). وClaude Code الذي يُغلق والطلب مفتوح ينهي الجلسة. ما زالت أزرار الطلب تجيب عن مربع الحوار إن كان ما زال مفتوحًا (يُنظر الإجابات).

لتغيير مدة الانتظار:

AIPAGER_INTERACTIVE_TIMEOUT=300 aipager start    # بالثواني

ميزة الرسائل الصوتية لا تُثبَّت عبر Telegram#

يشغّل الزر [📦 تثبيت ميزة الرسائل الصوتية] المثبّت ويعدّل رسالته كل بضع ثوانٍ أثناء العمل (لا يزال مستمرًا… (٢٥ ث)). إذا فشل التثبيت، تعرض الرسالة رمز الخروج وآخر ٥٠٠ حرف من مخرجات المثبّت. الأسباب الشائعة:

• الشبكة: pip لا يصل إلى PyPI. يلزم فحص الاتصال من الكمبيوتر الذي يعمل عليه aipager.
• القرص: يحتاج ‎~/.cache/huggingface/‎ إلى نحو ٧٤ ميغابايت للنموذج، وذاكرة wheel المؤقتة لـ pip إلى نحو ٢٥٠ ميغابايت أخرى. يلزم إخلاء مساحة أولًا.
• ‏Permission denied: البيئة الافتراضية للقراءة فقط. الحل الانتقال إلى uv tool install، الذي يستخدم دائمًا بيئة افتراضية يملكها مستخدمك.

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

فتح التطبيق يعرض «يُرجى فتح هذه الصفحة من تطبيق Telegram لتسجيل الدخول.»#

تحمّلت الصفحة، لكن سكربت Mini App SDK من Telegram (الذي ينتج initData) لم يتحمّل، فلا شيء لدى الصفحة لتسجيل الدخول به ولا ترسل أي طلب إلى الواجهة البرمجية. الرسالة تلومك؛ والسبب في الحقيقة يتعلق بالشبكة.

الإصدارات الحديثة من aipager تجلب ذلك السكربت بنفسها وتقدّمه من مصدر الصفحة نفسه (‎/telegram-web-app.js)، فلا يحتاج الهاتف إلا إلى الوصول إلى الخادم الذي قدّم الصفحة، لا إلى telegram.org أيضًا. إذا ظهر هذا في إصدار قديم، يلزم التحديث.

ثم، بالترتيب:

1. النظر في مصدر الصفحة. إذا كان وسم ‎<script>‎ يشير إلى https://telegram.org/js/telegram-web-app.js، فإن aipager لم يتمكن بعد من جلب السكربت والصفحة تحمّله من Telegram احتياطًا، وهذه بالضبط الحالة التي تفشل على هاتف لا يصل إلى telegram.org. يجلبه aipager عند بدء خادم Mini App ويعيد المحاولة مرة في اليوم على الأكثر، لذا فإعادة تشغيل aipager تعيد المحاولة فورًا؛ ويبيّن journalctl --user -u aipager | grep "webapp sdk"‎ ما الخطأ (عادةً telegram.org محظور أو مُرشَّح).
2. إذا كان الوسم يشير إلى ‎/telegram-web-app.js، يلزم التحقق من أن aipager يقدّمه: يجب أن يجيب curl -sI http://127.0.0.1:8765/telegram-web-app.js على كمبيوتر aipager (مع تعديل المنفذ إن غيّرته) بـ 200 مع Content-Type: application/javascript. النسخة موجودة في ‎~/.local/share/aipager/webapp-sdk/‎.
3. فُتح العنوان في متصفح عادي بدل زر ‎/app أو زر القائمة في البوت: عندها هذه الرسالة متوقعة. لا ينتج SDK قيمة initData إلا داخل Telegram.
4. بقيت الصفحة مفتوحة أكثر من خمس دقائق: تنتهي صلاحية initData وتطلب الصفحة إعادة فتحها. يكفي الضغط على ‎/app مرة أخرى.
5. ضُغط ‎📱 App في لوحة مفاتيح من إصدار أقدم من aipager: لا يعطي Telegram تطبيق Mini App المفتوح من زر في لوحة المفاتيح أي initData، ولذلك لم تعد لوحة aipager تضم هذا الزر. يكفي إرسال ‎/start للحصول على اللوحة الحالية، ثم فتح التطبيق من زر القائمة أو بـ ‎/app.

pyexpat _XML_SetAllocTrackerActivationThreshold عند التثبيت بـ brew#

حزمة python@3.12 من Homebrew بُنيت على libexpat أحدث مما في نظامك، والسبب في كل الحالات تقريبًا أن Xcode وCommand Line Tools قديمان على macOS Tahoe (26.x). مخرجات brew نفسها تقول ذلك عادةً. حلّان:

• استخدام uv tool install aipager بدلًا من ذلك. يجلب uv إصدار python الخاص به، فيتجنب المشكلة تمامًا. هذا هو الطريق الموصى به على macOS؛ يُنظر README.

• تحديث Xcode وCommand Line Tools:

  shCopy

  sudo rm -rf /Library/Developer/CommandLineTools
  sudo xcode-select --install
  

  أو فتح Xcode في App Store وتحديثه إلى الأحدث.

«ModuleNotFoundError: aipager»#

يشير برنامج aipager لديك إلى Python لم يعد aipager مثبّتًا فيه (غالبًا بعد حذف البيئة الافتراضية). الحل إعادة التثبيت:

uv tool install --reinstall aipager
# أو بالمثبّت الذي استخدمته من البداية: pipx، brew، pip

قائمة الجلسات ضاعت أو تلفت#

يحفظ aipager جلساته في ‎~/.claude/aipager-sessions.json، ويعيد كتابته بشكل ذري (ملف جديد، ثم إعادة تسمية)، فالكتابة المقطوعة تترك الملف القديم سليمًا. إذا كان الملف رغم ذلك غير موجود، أو غير مقروء، أو ليس JSON صالحًا، يكتب aipager في السجل أنه يبدأ من جديد (تحذيرًا حين يكون الملف موجودًا لكن غير مقروء) ويبدأ بقائمة فارغة؛ ولا يتوقف. لا توجد نسخ احتياطية لهذا الملف. لا يضيع شيء مهم:

• الجلسات الجارية يُعثر عليها مجددًا في أول دورة مراقبة، عبر مقابس dtach الخاصة بها (‎/tmp/claude-dtach-*.sock)؛
• كل محادثة ما زالت في مجلد Claude Code نفسه ‎~/.claude/projects/...‎، لذا فإن aipager session <name> --continue في مجلد تلك الجلسة يكملها (و‎--resume يتيح الاختيار)؛
• ما يضيع هو قائمة الجلسات المنتهية (‎/resume)، والبطاقات التي كانت مفتوحة، وبقية ما تذكّره aipager عن كل جلسة.

إذا ظل aipager يفشل عند البدء، يبيّن aipager logs (أو journalctl --user -u aipager) السبب؛ ونقل الملف جانبًا (mv ~/.claude/aipager-sessions.json ~/aipager-sessions.json.old) يستبعده من الشك.

بدء جلسة يفشل#

البدء الذي يرفضه dtach يعرض سببًا في سطر واحد في الدردشة (المقبس موجود مسبقًا، أو الطرفية غير قابلة للتشغيل، أو لا توجد طرفية وهمية، أو الاسم طويل جدًا، أو الإذن مرفوض، أو المجلد غير موجود)؛ ورسالة dtach نفسها، مع المسارات، موجودة في aipager logs.

قائمة فحوص aipager doctor#

الترتيب مهم: كل فحص لاحق يفترض نجاح ما قبله. الفحص الذي يتعطل بسبب بيئة غير متوقعة يظهر كسطر ⚠ واحد يذكر الفحص والخطأ؛ وتعمل بقية الفحوص.

يطبع aipager doctor --json الفحوص نفسها، بهذا الترتيب، بهذه المفاتيح (يُنظر الأوامر).

يشغّل aipager doctor --fix بحثًا تفاعليًا عن بيانات اعتماد Claude ونسخها إلى daemon.env (حتى حين يكون الملف موجودًا ولا يحتوي على أي منها)، أو تثبيت claude_path حين يُعثر على أكثر من تثبيت. لا يتصرف إلا بعد السؤال. ولخدمة ينقص PATH فيها مجلدُ claude، يُشغَّل aipager service install --yes.

aipager لا يجد claude، أو يختار التثبيت الخطأ#

كانت ستة مواضع تبحث عن claude كلٌّ بطريقته وقد تختلف نتائجها. الآن كلها تمر عبر باحث واحد (aipager/claude_resolve.py). claude_path في aipager.yaml، ثم ‎$AIPAGER_CLAUDE_BIN، يغلبان مباشرة إن كانا يعملان. وإلا فكل claude يُعثر عليه في ‎~/.local/bin وفي ‎$PATH وفي مجلدات Homebrew يُفحص، ويغلب الإصدار الأحدث (لذا لا يغيّر إعادة ترتيب ‎$PATH الاختيار حين يكون التثبيت الآخر أحدث). يعرض aipager doctor بالضبط ما اختاره وما الذي وجده غيره؛ وإن غلب الخطأ، يُثبَّت الصحيح:

aipager doctor --fix        # اختيار تفاعلي بين التثبيتات التي عُثر عليها
# أو يدويًا:
echo 'claude_path: /home/you/.local/bin/claude' >> ~/.config/aipager/aipager.yaml

الجلسات لا تستطيع تسجيل الدخول تحت خدمة systemd، لكن claude يعمل جيدًا في الطرفية#

خدمات systemctl --user لا تقرأ أبدًا ‎~/.bashrc /‏ ‎~/.profile، لذا فسطر export CLAUDE_CODE_OAUTH_TOKEN=…‎ هناك لا يصل أبدًا إلى aipager. بدلًا من ذلك تستخدم الخدمة LoadCredential=‎ من systemd، وتقرأ ‎~/.config/aipager/daemon.env: ملف KEY=VALUE بسيط، بالصلاحية 0600، يُنشأ تلقائيًا أول مرة يُشغَّل فيها aipager service install (يُنقل من config.env قديم إن كان فيه توكن، وإلا يُبحث عنه مرة واحدة في طرفية تسجيل الدخول لديك، وإلا يُترك فارغًا مع تحذير). إذا بقي فارغًا، يبحث aipager doctor --fix في المواضع نفسها مرة أخرى عند الموافقة ويضيف السطر الذي يجده، مع إبقاء الأسطر الأخرى في الملف؛ ولا يطبع التوكن أبدًا. أو يمكنك إضافة السطر بنفسك:

cat ~/.config/aipager/daemon.env          # رؤية ما فيه (أو ما ليس فيه)
echo 'CLAUDE_CODE_OAUTH_TOKEN=sk-...' >> ~/.config/aipager/daemon.env
chmod 600 ~/.config/aipager/daemon.env
aipager service stop && aipager service start

يُنظر نموذج الأمان: بيانات اعتماد Claude لما يحميه هذا الملف وما لا يحميه.

مقبس التحكم في aipager تغيّر مكانه#

كان aipager doctor /‏ aipager status ينظران دائمًا إلى ‎/tmp/aipager.sock. تحت خدمة systemd أصبح مقبس التحكم الآن في ‎$XDG_RUNTIME_DIR/aipager.sock (ويعود إلى ‎/tmp فقط حين لا يكون ‎$XDG_RUNTIME_DIR مضبوطًا: الحاويات، وWSL1، والتوزيعات المصغّرة). لم ينتقل إلا هذا المقبس؛ أما مقابس dtach لكل جلسة (‎/tmp/claude-dtach-*.sock) فلم تتأثر. يمكن ضبط AIPAGER_SOCKET_PATH عند الحاجة إلى مكان محدد.

‎/update يقول إن إعادة التشغيل ستُنهي الجلسات (KillMode)#

ملفات الخدمة المكتوبة قبل هذا الإصدار ليس فيها سطر KillMode=‎، لذا يستخدم systemd القيمة control-group: إيقاف aipager.service أو إعادة تشغيله يُنهي كل جلسة Claude بدأها aipager. لذلك يثبّت ‎/update الإصدار الجديد دون أن يعيد تشغيل aipager، ويسرد الجلسات التي ستُسقطها إعادة التشغيل. الإصلاح مرة واحدة:

aipager service install

يعيد هذا كتابة الخدمة مع KillMode=process، ويعيد تحميل systemd، ويعيد تشغيل aipager، وإعادة التشغيل تلك تعمل بالإعداد الجديد أصلًا. للتحقق: systemctl --user show -p KillMode aipager.service (KillMode=process). ومعه يكتب systemd أسطر «left-over process» لجلساتك عند كل إعادة تشغيل؛ وهذا متوقع.

aipager update لا يجد uv /‏ pipx#

يبحث aipager update عن المثبّت بمسار مطلق في PATH لديك، إضافة إلى ‎~/.local/bin و‎~/.cargo/bin ومجلدات Homebrew و‎/usr/bin و‎/bin. إذا ظل يقول إنه لم يجد pipx، فالمثبّت الذي أنشأ هذا الـ aipager لم يعد موجودًا أو موجود في مكان آخر؛ الحل إعادة التثبيت بالأداة المتوفرة (pipx install --force aipager،‏ uv tool install --reinstall aipager).

التحديث مرفوض: editable أو ليس تثبيتك#

لا يحدّث ‎/update وaipager update إلا تثبيتًا يملكه مستخدمك ويستطيع الكتابة فيه، عبر المثبّت الذي أنشأه. ويرفضان، مع ذكر السبب، في هذه الحالات:

• نسخة شيفرة بوضع editable (للتطوير): تُحدَّث بـ git pull؛
• تثبيت عبر Nix أو Snap أو Docker أو حزمة نظام: يُستخدم تحديث ذلك النظام نفسه؛
• تثبيت يملكه مستخدم آخر (مثل بيئة افتراضية يملكها root تحت ‎/opt): يُحدَّث بصفة ذلك المستخدم؛
• تثبيت من مجلد محلي (pipx install /path/to/aipager): لا يمكن التحديث من هنا: it was installed from a local folder; update it from that folder. يُجلب الإصدار الجديد إلى ذلك المجلد ويُعاد التثبيت منه، أو الانتقال إلى PyPI بـ pipx install --force aipager؛
• تثبيت لا يمكن معرفة مثبّته (could not tell which installer owns this aipager): إعادة تثبيته بـ uv tool install aipager أو pipx install aipager.

فشل التحديث: unexpected argument '--refresh'#

كان aipager 1.0.0 وما قبله يشغّل uv tool upgrade aipager --refresh، الذي لا يقبله أي إصدار من uv، فكان كل تحديث لتثبيت uv يتوقف مع error: unexpected argument '--refresh' found ولا يعيد تشغيل شيء. الإصدارات الأحدث تشغّل uv tool upgrade aipager. لتجاوز ذلك مرة واحدة، يُحدَّث من طرفية على ذلك الكمبيوتر (aipager update في تلك الإصدارات فيه المشكلة نفسها):

uv tool upgrade aipager
systemctl --user restart aipager.service

دون الخدمة (أو على macOS)، يُعاد تشغيل aipager بالطريقة التي بدأ بها.

تحديث Claude Code: مثبّت بـ npm في مجلد لا يمكنك الكتابة فيه#

‏Claude Code المثبّت بـ sudo npm install -g يوجد في مجلد لا يغيّره إلا root (مثل ‎/usr/lib/node_modules)، لذا يفشل claude update المشغَّل بمستخدمك مع global folder isn't writable. يعرض ‎/update وMini App الإصدار الأحدث مع لا يمكن التحديث من هنا: installed with npm into a folder your user can't write to ودون زر له. الحل تشغيل claude install مرة واحدة بالمستخدم الذي يعمل به aipager: ينتقل إلى مثبّت Claude Code الخاص به تحت مجلدك الرئيسي، الذي يحدّث دون sudo. ثم إعادة تشغيل aipager (systemctl --user restart aipager.service، أو بالطريقة التي بدأ بها): aipager الجاري يحتفظ بـ Claude Code الذي وجده عند البدء، وبعد إعادة التشغيل يأخذ الأحدث مما يجده. إذا كان claude_path في aipager.yaml (يمكن لـ aipager doctor --fix ضبطه) أو AIPAGER_CLAUDE_BIN يشير إلى نسخة npm، يُوجَّه إلى ‎~/.local/bin/claude أو يُحذف أولًا، لأنهما يغلبان دائمًا.

حُدّث، لكن الإصدار لم يتغير#

تثبيت pipx المصنوع من رابط git يُحدَّث من مصدر git ذلك، لا من PyPI. حين لا يكون في المصدر شيء أحدث، يقول ‎/update:‏ ✅ aipager على A بالفعل - تثبيت pipx هذا يُحدَّث من مصدر git الخاص به، ولا يوجد هناك إصدار أحدث.. الحل دفع الإصدار الجديد إلى هناك أو اختياره، أو الانتقال إلى PyPI بـ pipx install --force aipager.

دون خدمة، يثبّت aipager الذي لا يعيد تشغيله أي مدير خدمات (aipager start في طرفية أو tmux، أو Docker، أو launchd) التحديثَ لكنه يظل يشغّل الشيفرة القديمة حتى يُعاد تشغيله. عندها يعرض ‎/update السطر aipager B مثبت وينتظر إعادة التشغيل (يعمل الآن A).، وقد تكون هوكات Claude Code، التي تبدأ من جديد مع كل حدث، تشغّل B بالفعل: يتلقى المالك إشعارًا واحدًا بأن التحديث اكتمل نصفه فقط (بعد دقيقتين من أول تشغيل للهوكات بالإصدار B، فإعادة التشغيل التي تلي التثبيت مباشرة لا تُظهره أبدًا، وحين لا تجري أي مهمة في الدردشة الخاصة للمالك). حين يعمل aipager بالإصدار B، يصبح ذلك الإشعار ✅ اكتمل تحديث aipager: أصبح aipager يعمل بالإصدار B الآن. دون زرّه. يكفي الضغط على 🔄 إعادة التشغيل الآن (في رسالة التحديث، أو في الإشعار، أو في الإعدادات ← التحديثات في Mini App). ينتظر aipager حتى لا تجري أي مهمة، ثم يتوقف بشكل نظيف ويشغّل الإصدار الجديد في مكانه: العملية نفسها في الطرفية أو نافذة tmux أو الحاوية نفسها، بالأمر نفسه والبيئة نفسها.

إذا فشل التشغيل في المكان، تشغّل نسخة منفصلة aipager بعد أن تنتهي العملية القديمة. عندها يذهب خرجها إلى سجل إعادة التشغيل الذاتي (aipager.log في مجلد النسخة المثبتة، أو ‎/tmp/aipager.log) بدلًا من طرفيتك، ويذكر سجل aipager الأمر الذي عليك تشغيله إذا لم تعد تلك النسخة. إذا اختفى المفسّر نفسه (حُذفت بيئته)، أو لم يمكن تشغيل أي شيء، يخرج aipager بالرمز 1، وينتهي سجل aipager بـrestart.failed:‎ والأمر الذي عليك تشغيله، ويعلن التشغيل التالي عن التحديث.

حين لا يوجد زر إعادة التشغيل الآن، تعطي الرسالة الخطوات المناسبة لإعدادك: في طرفية أو tmux، الضغط على Ctrl+C ثم تشغيل aipager start؛ وعلى macOS،‏ launchctl kickstart -k gui/<uid>/com.aipager.daemon؛ وفي Docker،‏ docker restart <container>‎ على الكمبيوتر الذي يعمل عليه Docker. إعادة إنشاء حاوية Docker (docker compose up بعد down، أو docker run مرة أخرى) تشغّلها من صورتها، وهذا يعيد إصدار aipager الموجود في تلك الصورة: وللاحتفاظ بإصدار أحدث من aipager، يلزم استخدام صورة أحدث.

aipager لم يعد بعد التحديث#

يتحقق التحديث من أن الإصدار الجديد يُستورد قبل أي إعادة تشغيل، لكن إذا ظل aipager الجديد يفشل في البدء، يعيد systemd المحاولة كل ٥ ثوانٍ. لمعرفة السبب:

journalctl --user -u aipager.service -n 50

إعادة تثبيت الإصدار السابق بالمثبّت نفسه، ثم إعادة التشغيل:

pipx install --force aipager==<previous>        # أو:
uv tool install --force aipager==<previous>     # أو:
<venv>/bin/python -m pip install aipager==<previous>
systemctl --user restart aipager.service

تثبيت pipx من مسار محلي: pipx install --force /path/to/aipager عند الـ commit القديم. إذا كان هناك إعلان قديم ينتظر، يُحذف بـ rm -f ~/.local/share/aipager/update-restart.json (يُتجاهل بعد ٢٤ ساعة على أي حال)؛ و‎~/.local/share/aipager/update.lock مجرد ملف قفل وحذفه آمن حين لا يجري أي تحديث.

«انقطع تحديث حين توقف aipager»#

توقف aipager (أو أُعيد تشغيله) بينما كان ‎/update يثبّت، فتوقف المثبّت معه، لذا قد يكون التثبيت مكتوبًا نصفه. إذا لم يعمل aipager أو Claude Code كما يجب، يلزم الإصلاح: لـ aipager، تشغيل أمر إعادة التثبيت المذكور في الرسالة (مثل pipx install --force aipager) ثم systemctl --user restart aipager.service؛ ولـ Claude Code، تشغيل claude update مرة أخرى.

إذا لم يستطع «إعادة التشغيل الآن» تشغيل aipager من جديد (دون خدمة)، يترك restart.failed:‎ في سجل aipager مع الأمر الذي عليك تشغيله؛ وبعد تشغيله يعلن aipager الجديد عن التحديث.

دردشة بلغة خاطئة#

لغة aipager تأتي مما اختير للدردشة، لا من الرسائل فيها. فتح ‎/language في تلك الدردشة واختيار اللغة المطلوبة: هذا الاختيار يغلب كل شيء آخر. في الدردشة الخاصة، يتبع تلقائي لغة تطبيق Telegram لديك (الإعدادات ← اللغة في Telegram)؛ واللغة التي لا يملكها aipager تظهر بالإنجليزية. الدردشة الخاصة الموجودة قبل إضافة اللغات تبقى بالإنجليزية حتى اختيار لغة. والمجموعة بالإنجليزية حتى يختار مشرف لغتها. اللغة لا تغيّر إلا نصوص aipager نفسه: يجيب Claude بلغة الرسالة التي تصله، مهما عرض aipager. يُنظر اللغات.

وصف البوت ليس الذي كتبته#

يضبط aipager وصف البوت ووصفه القصير بكل لغة يتحدثها، للأشخاص الذين تطبيق Telegram لديهم بتلك اللغة، ويعرض Telegram ذلك النص لهم بدل النص الذي كتبته في BotFather. لا يفعل aipager ذلك إلا ما دام ليس لديك وصف خاص بك، لذا فالوصف المكتوب قبل تثبيت هذا الإصدار يصل إلى الجميع. إذا كتبته بعد أن ضبط aipager وصفه، فمن يستخدمون تلك اللغات ما زالوا يرون وصف aipager. لكي يروا وصفك، يُمسح نص aipager لكل لغة عبر Bot API (setMyDescription وsetMyShortDescription بنص فارغ وlanguage_code تلك اللغة)؛ ولا يضبطه aipager مرة أخرى ما دام وصفك موجودًا.

aipager يقول إن languages.json تعذّر استخدامه#

يحفظ aipager ما تعلّمه عن اللغات (من كان هنا قبل إضافة اللغات، وآخر لغة Telegram رآها لدى كل شخص، وهل أُرسل العرض الذي يأتي مرة واحدة وسطر الترحيب الأول) في ‎~/.local/state/aipager/languages.json. إذا تعذّرت قراءة ذلك الملف، ينقله aipager جانبًا إلى languages.json.bad-<time>‎ في المجلد نفسه، ويكتب تحذيرًا في السجل (مرة أخرى عند كل بدء حتى يُتخذ قرار)، ويُبقي كل دردشة بالإنجليزية دون أي عرض للغة حتى يُتخذ قرار: إعادة الملف القديم إن أمكن إصلاحه، أو حذف languages.json ثم إعادة التشغيل، فيعدّ aipager كل شخص يعرفه موجودًا من قبل (الإنجليزية حتى يختار). اللغة التي اختارها أي شخص ليست في هذا الملف ولا تضيع أبدًا.

النص من اليمين إلى اليسار يبدو خاطئًا#

في الفارسية والعربية، يضع aipager علامات اتجاه غير مرئية في نصه حتى يُقرأ كل سطر من اليمين إلى اليسار، ويُبقي أسماء الجلسات والأوامر والشيفرة من اليسار إلى اليمين. إذا ظل سطر يبدو مختلطًا، فالسبب في الغالب تطبيق Telegram يرسم النص مختلط الاتجاه بطريقة مختلفة: يمكن التحقق منه في تطبيق آخر (الهاتف مقابل Desktop أو Web) قبل الإبلاغ عنه. إجابات Claude نفسها تُعرض كما كتبها Claude، دون إضافة أي علامات.

كلمة لوحة مفاتيح مترجمة لا تفعل شيئًا في دردشة أخرى#

لوحة مفاتيح الرد في كل دردشة بلغة تلك الدردشة. كلمات لوحة المفاتيح الرئيسية (status وstop وnew وkill والبقية) مفهومة في كل دردشة، بكل لغة، والكلمات الإنجليزية تعمل دائمًا. أما كلمة زر قالب أو أمر فمختلفة: إذا كُتبت في دردشة مضبوطة على لغة أخرى، فهي رسالة إلى Claude لا زر، لذا فكلمة «مسح المحادثة» العربية لا تشغّل أبدًا ‎/clear في دردشة فارسية أو إنجليزية. الحل استخدام الزر نفسه، أو الأمر الإنجليزي (‎/clear). إذا بدت لوحة المفاتيح قديمة بعد تغيير لغة الدردشة، يُرسل ‎/start للحصول على الحالية. الكلمة التي هي أيضًا اسم إحدى جلساتك تخاطب تلك الجلسة. يقرأ ‎/mode الكلمات ask وauto وfull كوضع دائمًا، ويقرأ كلمة الوضع المترجمة كاسم جلسة فقط حين يكون لجلسة جارية هذا الاسم بالضبط.

ما زالت المشكلة قائمة؟#

إرسال تقرير مشكلة: الضغط على الإبلاغ عن مشكلة تحت ‎/help في دردشتك الخاصة مع البوت، أو تشغيل aipager report في طرفية. يظهر لك التقرير كاملًا قبل إرسال أي شيء، ولا يحتوي على دردشات أو رسائل أو أسماء أو مسارات أو توكنات (يُنظر تقارير المشكلات). بعد الإرسال يصلك رقم مرجع مثل ap1-7c41d09e2b3a.

ثم، إن رغبت في مناقشة الأمر، يمكنك فتح issue في github.com/dev-aly3n/aipager/issues وذكر رقم المرجع ذاك. يُرجى عدم لصق مخرجات aipager doctor أو aipager logs في issue: ففيها معرّف دردشتك، ومسارات مجلدك الرئيسي، وأسماء الجلسات، وبدايات رسائلك. إذا احتاج المطوّر سطرًا من السجل، فسيطلب ذلك السطر وحده، ويمكن حذف أي شيء خاص منه أولًا.

صفحات ذات صلة#

• البنية: ما يفعله كل جزء.
• نموذج الأمان: ما يلمسه aipager وما لا يلمسه.