المنهج اتلمّ.والـ tabs تهدى.

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

الموقف ده سيناريو توضيحي للنوع اللي Knownly بيحاول ينظّمه. مش بنحكي عن طالب قابلناه في دراسة بحثية، ولا بنطلع إحصائية من جيبنا. الفكرة بسيطة: المادة ليها سياق، والسياق ده محتاج مكان يرجع له صاحبه.

إحنا فريق Softworks بنينا Knownly حوالين الـ Space. مادة، هدف تعلّم، أو موضوع بتشتغل عليه، وتحته الملاحظات والمصادر والأدوات والمهام. تفتح مكان واحد، فتلاقي فيه الخيط اللي تقدر تكمل منه.

النسخة دي بتحكي نفس المشروع اللي في النسخة الاحترافية، بس بصوت أخف. هنضحك على زحمة الـ tabs، ونفهم الـ queues، ونشوف commits فعلية. مش هنقول إن زرار لطيف أصلح التعليم في المنطقة.

نص ميم منشور على لقطة من «مرجان أحمد مرجان»، وفيها مصطفى هريدي. دي نسبة للصورة والكابشن في الدهليز، مش تفريغ موثّق لحوار الفيلم.

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

خلّينا في قواعد البيانات. عندك تعريف normalization، ومثال عن كورسات وطلبة، ورسمة علاقات، وسؤال مراجعة. لو كل ده جنب بعض، تقدر تقرأ الفكرة وتشوف تطبيقها وتختبر نفسك. لو متفرق، غالبًا هتبدأ بسؤال: «هو المثال كان في أنهي ملف؟».

Knownly بيحافظ على العلاقة بين الحاجات دي. الصفحة تبع مادة. المصدر تبع نفس المادة. السؤال ينفع يعيش جوّه الملاحظة. والمحادثة تقدر تتفتح وهي عارفة السياق الحالي. كده التنظيم بيبقى مسؤولية المنتج كمان، بدل ما كله يبقى متساب لذاكرة الطالب.

الـ Space هي البيت اللي بيلمّ الموضوع. ليها اسم ووصف وشكل بصري وترتيب. جواها Pages للشغل، وMaterials للمراجع، ومعاها مهام ومواعيد مرتبطة بالموضوع.

الصفحة ليها ID وترتيب، وممكن تبقى تحت صفحة أم. محتواها متخزّن كـ JSONB عشان يستوعب blocks مختلفة. دي مرونة في جسم المستند، مع هيكل ثابت حواليه. يعني نقدر نحط كويز جنب شرح من غير ما ترتيب الصفحات يتحول لسؤال فلسفي.

الـ Material مختلف عن الصفحة. ده المرجع اللي بتشتغل عليه، وليه بيانات وحالة معالجة. ملف موجود في التخزين مش بالضرورة نصه جاهز للمساعدة الذكية. الفصل ده بيفرق لما الملف ياخد وقت في المعالجة أو النتيجة تحتاج إعادة محاولة.

وفيه مساحة شخصية معمولة بنفس النموذج. ما عملناش عالم تاني للملاحظات العامة بقواعد تانية، عشان المستخدم ما يتعلمش نظامين تنظيم لمجرد إنه عايز يكتب حاجة خارج مادة محددة.

المادة هنا Database Systems. مش لازم تسمّي ملفاتك «آخر نسخة بجد النهائي ٤» عشان تعرف ترجع للملاحظة.

نور في العرض ده شخصية خيالية. عنده مواد كتير ومواعيد وشغل كفاية إننا نشوف التطبيق وهو متعبّي. بيفتح مادة قواعد البيانات، يدخل على شرح العلاقات، ويقابل سؤال صغير تحت الفكرة.

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

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

ما عندناش هنا لقطة «نور جاب امتياز بسبب زرار الكويز». عشان نقول حاجة زي دي، نحتاج بحث وقياس وطلبة حقيقيين. نور موجود عشان يختبر شكل الرحلة، مش عشان يشتغل testimonial بالعافية.

الواجهة Next.js وReact. الـ API بـ Fastify. البيانات في PostgreSQL، والاستعلامات والمهاجرات عن طريق Drizzle. Redis وBullMQ للشغل اللي محتاج تنسيق أو يكمل في الخلفية. الملفات ليها تخزين منفصل متوافق مع S3.

جوا الـ backend، الـ routes بتستقبل الطلبات، والـ services بتعبّر عن سلوك الميزة، والـ repositories بتوصل للبيانات. التقسيمة دي بتخلّي المهندس اللي داخل يصلح حاجة يعرف يمسكها منين، بدل ما يفتح ملف ويلاقي فيه رحلة حياة المنتج كاملة.

الواجهة كمان بتفصل بيانات الخادم عن حالة التفاعل. TanStack Query بتتعامل مع البيانات والـ cache والتحديثات. Zustand بتتعامل مع حاجات زي اللوحة المفتوحة، وحالة الشريط الجانبي، وتفضيلات الواجهة.

وعشان المصطلحات ما تزوغش مننا: ده تطبيق بموديولات ومعاه workers. مش كل مربع في الرسمة بقى microservice لمجرد إننا رسمناه لوحده. شكل النشر والاستقلال التشغيلي ليهم شروط مختلفة.

اختيار اسم مشهور مش بيحل المشكلة لوحده. المكتبة بتديك أساس، وإنت مسؤول تربطه بالمنتج وتفهم حدوده. تركيب editor غني مع مكتبات كتير كمان بييجي مع تفاصيل توافق؛ الـ npm install المحلي طلع peer warnings، واتسجلت بدل ما نعتبرها اختفت عشان الصفحة فتحت.

خصّصنا schema للمحرر عشان يدعم quizzes وflashcards وKanban وجداول ورسومات ومعادلات وgraphs وأجزاء مرتبطة بالمهام. كل block ليها شكل بيانات وrenderer فاهمه.

يعني السؤال مش paragraph متنكّر. فيه اختيارات وإجابة وشرح. والكارت مش سطرين وخلاص؛ فيه تفاعل كشف الإجابة. ولو البيانات ناقصة، المكوّن محتاج يتعامل مع الحالة دي بدل ما ينهار في نص الصفحة.

كمان بنينا سياق المحادثة، وحالات الحفظ، وتنظيم المساحات، وربط المواد، ومسارات التوليد، ونسخ المساحات بعلاقاتها. الشغل ده هو اللي بيخلّي الأدوات جزء من منتج واحد، بدل معرض مكتبات كل واحدة بتعمل demo لوحدها.

وفيه أدوات قديمة اتجمّعت جوّه الملاحظات بدل صفحات مستقلة. بعض الأسماء لسه موجودة في constants، لكن الـ renderer الحالي بيقول إن النوع القديم اتوقف. ما خدناش كل اسم في enum وحطيناه في صفحة التسويق على إنه ميزة شغالة.

سيناريو هندسي توضيحي: الطالب بيكتب، يحط كويز، يفتح رسمة، ويرجع يكمل النص. كل أداة بتتصرف بشكل مختلف، لكن المستند لازم يفضل مفهوم.

حلّينا شكل المحتوى بالـ blocks. كل جزء ليه نوع وبيانات، والصفحة بتحافظ على ترتيبهم. كده نقدر نطوّر أدوات مختلفة من غير ما نحول جسم المستند لسلسلة استثناءات ملهاش آخر.

ومن ناحية التحميل، فيه أدوات تقيلة مش محتاجينها مع كل فقرة. بعض renderers بتتحمل dynamically، ومعاها حالات تحميل. ده قرار في إدارة dependencies وتجربة الانتظار. مش هنبص على سطر dynamic import ونكتب تحته «أسرع ٧٠٪» ونمشي.

وحالة التوليد ليها شكل. جاهز، لسه شغال، أو فشل ومحتاج محاولة. المستخدم يقدر يفهم الفرق. الـ skeleton مش شهادة إن كل حاجة تمام؛ هو بس وصف مؤقت للي بيحصل دلوقتي.

الطالب كتب، وقف ثانية، وبعدين كمل. أول save رجع، لكن فيه كلام أحدث. لو مؤشر الحفظ احتفل بأول رد من غير ما يعرف هو تبع أنهي تغيير، ممكن يطمن المستخدم بدري.

الـ hook بيعمل debounce لمدة ثانية، ويحتفظ بآخر محتوى محتاج حفظ، ويزود sequence مع كل جدولة. لما الرد يوصل، بيتقارن بالـ sequence الحالية قبل ما نغيّر حالة المؤشر.

يعني اللي وصل متأخر ما ياخدش المايك ويعلن نتيجة تخص حالة أقدم. المثال هزار، لكن ترتيب الأحداث هنا مسألة حقيقية في واجهات بتتعامل مع network غير لحظية.

وفيه محاولة flush وقت الخروج من الصفحة أو cleanup. ده مفيد في التنقل العادي، لكن مش معناه إن قطع الكهرباء بقى feature مدعومة. ما بنقولش offline editing، ولا collaborative conflict resolution، لأن الدليل اللي عندنا ما يثبتش دول.

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

فيه فرق بين «الملف اترفع» و«محتواه بقى جاهز للاستخدام». لو خلطناهم، هنلاقي المستخدم بيقول: أنا شايف الملف، ليه المساعد مش شايف اللي جواه؟

Knownly بيفصل metadata عن object storage وعن extracted text. العامل الخلفي يشتغل على المعالجة، ويحدّث حالة المصدر. الواجهة تفضل عارفة المصدر موجود فين ووصل لأنهي مرحلة.

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

العرض هنا فيه مصادر نصية خيالية. ده يخلينا نشوف التنظيم من غير اعتماد على ملفات جامعة أو بيانات ناس حقيقية. مسار PDF extraction موجود في الكود، لكن الصور مش اختبار OCR ولا إثبات دعم كل صيغة ممكنة.

كابشن ميم على لقطة من «الرهينة» فيها أحمد عز، موثّق في الدهليز. الاستخدام هنا تعليق على فقدان السياق.

لو الطالب جوّه ملاحظة قواعد بيانات وسأل «اشرح العلاقة دي»، يبقى محتاج إجابة مربوطة باللي قدامه. ولو فاتح التقويم وسأل «أرتب الأسبوع إزاي»، السياق مختلف تمامًا.

Knownly عنده context builder بيتعامل مع النوع ده من الاختلاف. سياق note، وسياق space، وسياق calendar، وسياق عام. يقدر يضيف محتوى الصفحة، ومصادر جاهزة، ونصوص annotations، أو مواعيد جاية، حسب نوع المهمة.

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

الرد بيتعرض تدريجيًا ويتخزن في مسار المحادثة. في العرض المحلي، الرد مكتوب مسبقًا ومعلّم بوضوح. جرّبنا به رحلة المتصفح والـ API والحفظ. ما سمّيناش ده اختبار ذكاء موديل، لأن الموديل هنا واخد أجازة والـ fixture بتقوم بالعرض.

سيناريو توضيحي: مسار تعلّم فيه عدة صفحات. واحدة خلصت، واحدة رجعت فاضية، واحدة فشلت. لو الواجهة بتقول loading للأبد، الطالب مش هيعرف يستنى ولا يعيد المحاولة ولا يروح يعمل شاي.

فيه workflows بتعمل هيكل الصفحات وترتيبها، وبعدها jobs للمحتوى. الـ worker ليه concurrency محدودة، وإعادة المحاولة ليها سياسة معروفة. بعد المحاولات الأخيرة، حالة الفشل تقدر تتسجل في الصفحة، والواجهة تعرض طريق للمحاولة تاني.

وفيه helper بيستخدم settled results عشان يحتفظ بالناجح ويعمل fallback للفاشل. مش كل مسار في المشروع نسخة من التاني؛ عشان كده وصفنا كل آلية بحدودها بدل ما نحشرهم في جملة واحدة شكلها حلو.

الفكرة اللي تهم المستخدم إن الشغل البطيء ليه حالة. اللي خلص يبان، واللي مستني يتفهم، واللي فشل يبقى واضح. الطابور هنا جزء من تنفيذ السلوك ده، مش بطولة مستقلة في صفحة الـ Tech Stack.

مساحة فيها صفحات تحت صفحات، ومصادر متقسمة، ومسار تعلّم مرتب. المستخدم عايز ينسخها. لو نسخنا الصفوف وسيبنا علاقاتها شاورة على القديم، كده نقلنا العفش وسيبنا مفاتيح الأبواب في البيت الأول.

التنفيذ بيطلع IDs جديدة، ويحفظ mapping بين القديم والجديد. بعد كده يعيد توصيل علاقات الأبناء والآباء، ويربط ترتيب مسار التعلّم بالصفحات الجديدة. وكل ده داخل transaction.

المرحلتين ليهم سبب. قبل ما أوصل الطفل بالأب الجديد، لازم الأب الجديد يبقى موجود ومعروف ID بتاعه. ترتيب التنفيذ هنا هو اللي بيحافظ على معنى التنظيم، مش مجرد عدد السجلات اللي اتكتبت.

المستخدم مش لازم يشوف كل التفاصيل دي، لكنه بيحس بنتيجتها. يفتح النسخة، يلاقي المحتوى في مكانه وعلاقاته مفهومة. دي نقطة إن الشغل التقني الكويس أوقات بيبان كأن «الحاجة اشتغلت عادي».

الأمثلة اللي فاتت بتشرح سيناريوهات التصميم. هنا بقى فيه تغييرات فعلية اتراجعت في Git. وهي موجودة على فروع تطوير منفصلة عن main اللي اتصور. الفصل ده مهم عشان ما نخلطش كواليس التطوير مع النسخة المعروضة.

المصطلح الدقيق كان محتاج يتشاف وسط المعنى

Commit 87f6ace في ٢٣ أغسطس ٢٠٢٦ أضاف hybrid retrieval. فيه مرشحين جايين من semantic search، ومرشحين جايين من lexical search في PostgreSQL. بعد كده النتائج بتتجمع، وتتوزن بالترتيب، وتتفلتر قبل اختيار المجموعة النهائية.

تخيّل سؤال فيه اختصار تقني. التشابه في المعنى مفيد، لكن الكلمة نفسها ساعات بتبقى مفتاح. الجمع بين الإشارتين بيحاول يحافظ على الاتنين. دي آلية واضحة في التغيير؛ مفيش جنبها benchmark يسمح نقول إنها حسّنت النتائج بنسبة من خيالنا.

البديل اترفض؟ القائمة لسه فيها ناس

في 7404a9c، مسار RAG اتعدل عشان يكمل بعد رفض موديل من بدائل الـ fallback. وجود خمس أسماء في array مش معناه إن التنفيذ هيجربهم كلهم تلقائيًا. مسار الخطأ لازم يخلّيه يوصل للي بعده.

دي من التفاصيل اللي سهل تتفوت لو كل الاختبارات بتبص على الرد الناجح بس. وإحنا هنا بنحكي التغيير المحدد، مش بنعلن إننا لغينا فكرة تعطل الـ providers من الكون.

الاقتراح كان بيقبل نفسه ويوقف نفسه

Commit 36c65dd في ٢٦ أغسطس اتعامل مع حالة أثناء إدخال اقتراح autocomplete حرف بحرف. الإدخال نفسه بيغيّر المستند، وحدث التغيير ممكن يشغّل منطق الإلغاء اللي المفروض يتعامل مع كتابة المستخدم.

الـ guard فرّق بين «المستخدم بيكتب» و«المحرر بيكمّل إدخال اقتراح تم قبوله». نفس الحدث على السطح، لكن معناه مختلف. من غير التفريق، العملية ممكن تتخانق مع cleanup بتاعتها وهي شغالة.

Shift+Tab مش تصريح مفتوح للموافقة

Commit c192c97 أضاف guards للمفاتيح المركبة، وعدّل التعامل مع نهاية SSE، وحط سقف للـ suggestion cache. ثلاث تفاصيل صغيرة، لكن كل واحدة فيهم في قلب تجربة كتابة متكررة.

الـ commit فيه اختبارات. كويس، لكن إحنا ما شغّلناش اختبارات الفرع ده في تحقق main. مش هننقل عدد مذكور في الرسالة ونحطه فوق الصفحة كأنه نتيجة test run حصل دلوقتي.

المستخدم محدد نص… سيبه يخلص اللي بيعمله

في 21376e4 الاقتراحات بتتوقف أثناء selection. وفي de63f80 العناوين بتتنضف من مسافات زيادة، والمرشح اللي ملوش عنوان بيتشال. الاقتراح محتاج يظهر في توقيت مناسب وباسم مقروء، وإلا الذكاء نفسه هيتحوّل لمقاطعة.

اللي بنشوفه في الحكايات دي إن AI جوّه محرر محتاج هندسة interaction. الرد اللطيف جزء من الموضوع؛ التوقيت، والإلغاء، والقبول، وعمر الكاش أجزاء تانية لازم تاخد حقها.

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

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

فيه light وdark، وكمان Solarized وNord وDracula. الصور اللي راجعناها هنا لشاشات مختارة في light وdark. ما أخدناش عدد الـ themes وحوّلناه لشهادة إن كل الحالات في كل الأوضاع اتراجعت.

التقويم بيجمع المواعيد. المذاكرة نفسها لسه محتاجة صاحبها يحضر.

عندنا ٨ مواد، و٤٨ ملاحظة، و٤٠ مصدر، و٢٤ مهمة، و٢٤ حدث في التقويم. ومعاهم مساحة شخصية التطبيق بيعملها. البيانات دي خيالية ومتولدة عشان نراجع الحالات اللي فيها محتوى كتير.

مش ٤٨ عميل، ومش ٢٤ جامعة، ومش «نمو قياسي». دي أعداد fixtures، وسبب ذكرها إن القارئ يعرف الصور اتعملت على إيه. لما تقول الرقم بيقيس إيه، الرقم نفسه يبقى مفيد.

شغّلنا PostgreSQL وRedis وتخزين ملفات محلي، ومررنا migrations، وعملنا builds وlint واختبارات تكامل. المحادثة التجريبية عدّت من مسار التطبيق واتحفظت. تعديل المحرر ظهر بعد reload. وبعدها اتصورت شاشات فعلية في الوضعين.

الموديل الحي، والدفع الحقيقي، وتكامل LMS، والتحميل الإنتاجي الكبير خارج الاختبار ده. عشان كده مفيش صورة هنا متنكرة في هيئة production certification.

الكابشن متداول على لقطة من «اللعب مع الكبار» فيها عادل إمام، حسب الدهليز. كلمة «البوستات» هنا جزء من الميم، مش بننسبها لحوار الفيلم الأصلي.

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

وجوا التنفيذ فيه قرارات صغيرة ليها أثر: save sequence، وحالة معالجة للمصدر، وworker بعدد مهام محدود، وmapping وقت نسخ المساحات. وعلى الفروع فيه شغل موثّق على retrieval والـ autocomplete والـ backlinks.

ده النوع اللي ينفع نحطه في case study هندسية. شرح للمشكلة، وقرار، وطريقة تنفيذ، وحد للدليل. مش لازم نخترع أزمة الساعة ٣ الفجر عشان نثبت إن الشغل كان محتاج تفكير.

المعلومة محتاجة علاقتها. تخزين الشرح لوحده أسهل من الحفاظ على صلته بالمصدر والسؤال والميعاد، لكن العلاقة هي اللي بتخلي المنتج مفيد.

الانتظار محتاج تفسير. المستخدم يقدر يتعامل مع حاجة لسه بتتجهز لو فاهم وضعها. الـ spinner اللي ملوش نهاية مش تواصل.

المحرر كائن حساس للتوقيت. الكتابة، والاختيار، والتحديد، وقبول الاقتراح مش نفس الحالة. التعامل معاهم بنفس رد الفعل بيطلع مفاجآت.

النسخ محتاج فهم للهيكل. الصفوف الجديدة لازم تتوصل ببعض صح. مجرد نجاح INSERT مش آخر الحكاية.

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

يعني هو LMS كامل؟

النسخة اللي اتراجعت learning workspace. فيه scaffolding لتكامل LMS، لكن Canvas sync مش مكتملة. اسم provider في schema ما يقومش مقام integration شغالة.

الـ RAG والـ autocomplete في الديمو؟

لأ. دول حكايات تطوير من فروع منفصلة. الصور من main، والبحث فيه على العناوين. ما حطيناش لقطة لميزة مش موجودة في النسخة المصوّرة.

الرد اللي في الصورة مكتوب؟

أيوه، ومكتوب عليه ده. والـ quizzes والـ flashcards fixtures برضه. العرض بيختبر التجربة ومسار البيانات، مش جودة التوليد.

التطبيق نفسه مصري؟

المقال هو اللي بالمصري. الصور من واجهة إنجليزية. دعم العربي وRTL داخل المنتج محتاج شغل وتحقق مستقلين.

الميمز جزء من النسخة الرسمية؟

الإشارات السينمائية القصيرة في النسخة الخفيفة بس. صور الأفلام مش منشورة هنا؛ اقرأ توضيح الإشارات. النسختين الاحترافيتين بيحكوا نفس الحقائق من غير الإشارات دي.

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

الخطوة الجاية: احكيلنا عن المنتج، والمواقف اللي المستخدم بيقف عندها.

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

الأدلة · صور التطبيق · مصادر الميمز