تنظيم الملفات للروايات الطويلة

ثمن الفوضى

في عام 1937، بدأ تولكين مشروعاً كان يظنه تكملة قصيرة لـ الهوبيت. بعد اثني عشر عاماً، أصبح ذلك المشروع سيد الخواتم -- نصف مليون كلمة عبر ثلاثة مجلدات. خلال تلك السنوات، أنشأ كتيبات قواعد للغات الإلفية، وخرائط بمقياس رسم لأرض الوسط، ومخططات أنساب ملكية تمتد عبر آلاف السنين الخيالية. كل معلومة كان لها مكان محدد. لم يُنهِ الكتاب لأن ذاكرته خارقة -- بل لأنه استطاع العثور على أي شيء يحتاجه.

هذه التفرقة تُغيّر كل شيء.

"الفصل3-النهائي-النهائي-فعلاً-هذه-المرة.docx". وراء هذا الاسم لا تكمن فقط مشكلة تسمية. ملفات الشخصيات مدفونة في زاوية ما على سطح المكتب. حوار كُتب قبل ثلاثة أشهر يعيش في نسخة مجهولة. هل البطل وحيد والديه أم لديه أخ أكبر؟ نصف ساعة بحث ولا جواب.

علم النفس يسمّي ما يحدث بعد ذلك "تكلفة التبديل بين المهام". كل قفزة من وضع الكتابة إلى وضع البحث عن ملف تُجبر الدماغ على إعادة التشغيل. مرة أو مرتين لا تُحدث فرقاً. عشر مرات في اليوم، سبعة أيام في الأسبوع، لثلاثة أشهر -- ما يتبدد ليس الوقت. إنها قوة الإرادة. عند الجلوس للكتابة يكون الإرهاق قد سبق. قبل كتابة كلمة واحدة، تظهر الرغبة في إغلاق الحاسوب.

السؤال الحقيقي إذن ليس "هل أُنظّم أم لا". بل كيف نبني نظاماً بأقل جهد ممكن -- نظاماً يُزيل "البحث عن الأشياء" من الوعي، نهائياً.

الكتاب كمستودع

واجه مهندسو البرمجيات هذا الجدار تماماً قبل عقود.

ملايين الأسطر من الشيفرة، عشرات الأشخاص يُحررون في الوقت نفسه -- ومع ذلك تبقى الإصدارات واضحة، والتاريخ قابلاً للتتبع، وأي نقطة زمنية يمكن استعادتها. ليس بذاكرة خارقة. بنظام التحكم في الإصدارات: معاملة المشروع بأكمله كمستودع منظم.

Slima تجلب هذا المنطق إلى الكتابة. عند فتح File Tree، يبدو كهيكل مجلدات عادي. لكن تحت السطح، كل تغيير في ملف يُتتبع. كل إصدار تاريخي يُحفظ. أي حالة سابقة يمكن زيارتها في أي وقت.

الكتاب يتوقف عن كونه كومة ملفات .docx متناثرة. يصبح مستودعاً ذا طبقات، وتاريخ، وذاكرة. العملية الإبداعية والنتيجة الإبداعية -- كلاهما محفوظ معاً.

يبدو كشيء يحتاجه المهندسون فقط؟ لنُعد التفكير. أي كاتب لم يشعر بلسعة "ليتني لم أُغيّر تلك الفقرة"؟

بناء الهيكل

إلى التطبيق العملي. هذا ما أثبت فعاليته.

هيكل مجلدات مُجرّب للروايات الطويلة:

روايتي/
├── المسودات/
│   ├── الجزء-الأول/
│   │   ├── 01-البداية.md
│   │   ├── 02-الصراع.md
│   │   └── 03-نقطة-التحول.md
│   ├── الجزء-الثاني/
│   └── الجزء-الثالث/
├── الشخصيات/
│   ├── الأبطال/
│   ├── الثانوية/
│   └── الأشرار/
├── العالم/
│   ├── الأماكن/
│   ├── التاريخ/
│   └── القواعد/
├── البحث/
└── المخططات/
    ├── المخطط-العام.md
    ├── مخططات-الفصول.md
    └── الجدول-الزمني.md

مبدأ واحد يحكم كل شيء: المسودات مع المسودات، الشخصيات مع الشخصيات، بناء العالم مع بناء العالم. التحقق من خلفية شخصية لا يتطلب الحفر في فصول المسودة. تأكيد وصف مكان لا يتطلب بحثاً شاملاً. أين يعيش كل شيء -- لا يحتاج تفكيراً.

هذا الفصل يحمل فائدة مخفية. AI Assistant في Slima يصبح أدق عندما تكون المعلومات منظمة. عند الإشارة لمجلد "الشخصيات/الأبطال" في AI Chat Panel (Cmd+Shift+A / Ctrl+Shift+A)، يفهم الذكاء الاصطناعي فوراً أن السياق هو تطوير الشخصيات -- وليس ميكانيكا الحبكة. مدخلات منظمة تُنتج إجابات منظمة.

الهيكل ليس شريعة أيضاً. في منتصف المسودة، اكتشاف الحاجة لمجلد "مشاهد-محذوفة"؟ يُنشأ. الحاجة لتقسيم "التاريخ" إلى قديم وحديث؟ يُقسّم. File Tree يدعم السحب والإفلات. إعادة التنظيم تشبه ترتيب مكعبات البناء.

فن التسمية

تسعون بالمئة من الكُتّاب يستهينون بتسمية الملفات.

الطريقة التقليدية: وضع رقم قبل كل شيء. 01-، 02-، 03-. المطورون يفعلون هذا لأن محررات الأكواد ترتّب أبجدياً. لكن File Tree في Slima يدعم السحب والإفلات للترتيب -- الملفات والمجلدات على حد سواء يمكن تحريكها مباشرة. لا حاجة لتشفير التسلسل في الاسم.

لذا يمكن للفصول أن تحمل عناوينها الحقيقية:

قبل-العاصفة.md
اللقاء.md
السر-الأول.md

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

ملفات الشخصيات تستفيد من تضمين الدور:

أحمد-البطل.md
الدكتور-سالم-المرشد.md
الظل-الشرير-الغامض.md

المكسب الحقيقي في البحث. عند استخدام Quick Open (Cmd+P / Ctrl+P)، كتابة "البطل" تُظهر كل ملف متعلق بالأبطال. كتابة "الشرير" تكشف كل الأشرار. لا حاجة لتذكّر اسم كل شخصية.

ملفات بناء العالم تحتاج أسماء وصفية:

✓ تاريخ-المملكة-الشمالية.md
✗ إعداد3.md

"إعداد3" قد يكون منطقياً يوم إنشائه. بعد ثلاثة أشهر؟ لغز كامل. "تاريخ-المملكة-الشمالية" لن يواجه هذه المشكلة أبداً.

إعادة التسمية سهلة -- اختيار الملف في File Tree، ضغط F2 للدخول في وضع التسمية. الروابط الداخلية تتحدث تلقائياً. لا مراجع مكسورة.

Version Control: شبكة الأمان التي تُغيّر كل شيء

نظام ملاحظات تولكين الورقي كان فيه خلل قاتل واحد.

ما يُغيّر، يضيع. العودة لإعداد من قبل ثلاثة أشهر؟ اختفى. إلا إذا كان قد نسخه بخط يده أولاً -- ومن ينسخ يدوياً قبل كل تعديل؟

Version Control في Slima يقضي على هذه المشكلة من جذورها. ضغط Cmd+Shift+G (ماك) أو Ctrl+Shift+G (ويندوز) يفتح خطاً زمنياً -- كل تعديل مُسجّل، كل حالة محفوظة.

Snapshots (اللقطات) هي نقاط حفظ يدوية. إنهاء فصل -- حفظ واحدة. الاستعداد لمراجعة كبيرة -- حفظ واحدة. وصلت ملاحظات Beta Readers والمشرط على وشك الخروج -- حفظ واحدة. أي لحظة تبدو فيها الحالة الراهنة "تستحق الاحتفاظ" تستحق لقطة.

لكن ما يُغيّر قواعد اللعبة فعلاً هو Branches (الفروع).

لا توجد أداة كتابة أخرى في السوق تقدم هذا. المفهوم بديهي: فتح خط استكشاف موازٍ دون المساس بالمسودة الرئيسية.

في منتصف الرواية، يخطر بالبال: "ماذا لو مات المرشد هنا؟" الطريقة التقليدية: نسخ المشروع بالكامل، التجريب في النسخة، حذفها إذا فشلت، الغرق في جحيم الإدارة إذا احتاجت النسختان التعايش.

في Slima، إنشاء فرع اسمه "experiment/mentor-dies". الكتابة بحرية داخله -- الخط الرئيسي لا يتحرك. راضٍ عن النتيجة؟ دمج الفرع. غير راضٍ؟ العودة للرئيسي. الفرع يبقى هناك، هادئاً، لا يتدخل في شيء.

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

تنظيم الفوضى الحالية

هناك بالفعل كومة ملفات متناثرة؟ هل فات الأوان؟

لم يفت أبداً.

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

التصنيف يأتي بعده. محتوى المسودات، ملفات الشخصيات، مواد بناء العالم، مراجع البحث، المخططات والخطط. بعض الملفات تقاوم التصنيف -- تذهب لمجلد "للترتيب". لا توقف هنا.

ثم بناء هيكل المجلدات في Slima، ونقل الملفات واحداً تلو الآخر لمواقعها الصحيحة، مع إعادة تسميتها في الطريق. ممل؟ نعم. لكنه يحدث مرة واحدة فقط.

لحظة الانتهاء، إنشاء لقطة فوراً. هذه اللقطة تُعلّم نقطة التحول -- من الفوضى إلى النظام.

غير متأكد من كيفية التصنيف؟ AI Assistant يمكنه المساعدة. فتح AI Chat Panel ولصق قائمة الملفات:

هذه كل الملفات في مشروع روايتي:

[قائمة الملفات]

أرجو اقتراح هيكل مجلدات مناسب بناءً على أنواع المحتوى، مع شرح غرض كل مجلد.

توصية مخصصة تصل خلال ثوانٍ.

البدء من الصفر مع مشروع جديد

مشروع طويل جديد في الأفق؟ هذه أفضل نقطة انطلاق ممكنة.

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

ملفات القوالب تستحق التحضير أيضاً. وضع "_قالب-شخصية.md" في مجلد الشخصيات بحقول معيارية: معلومات أساسية، مظهر، شخصية، خلفية، دور في القصة. شخصية جديدة؟ نسخ القالب وملء الفراغات. دون إعادة اختراع العجلة كل مرة.

الهيكل سيتطور مع نمو المشروع. قد تظهر مجلدات جديدة. بعضها قد يندمج. هذا طبيعي. إعادة تنظيم بالسحب والإفلات في File Tree، وVersion Control جاهز للتراجع عن أي خطأ -- لا تغيير لا رجعة فيه.

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

الأدوات تغيّرت. الورق أصبح Writing Studio. النسخ اليدوية أصبحت Snapshots. المقص والصمغ أصبحا سحباً وإفلاتاً في File Tree. لكن التفكير الأساسي لم يتغيّر -- معاملة الكتاب كمشروع يحتاج إدارة، وليس كومة ملفات مرمية عشوائياً.

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

المقالة التالية: قاعدة بيانات الشخصيات -- كيف نتتبع كل شخص في القصة كما تتبع تولكين سلالات أرض الوسط.