خانواده مصنوعات نشست SQLite در مسیر 3

این یادداشت دامنه clawdbot-d63.2 را مشخص می‌کند، درحالی‌که clawdbot-d63.1 مالک تابع کمکی هم‌پوشان بایگانیِ بازنشانی/حذف در src/config/sessions/session-accessor.sqlite.ts است. فایل پیاده‌سازی در طول این مرحله دارای تغییرات ثبت‌نشده بود؛ بنابراین، این مصنوع قرارداد دقیق و نقاط وصله را بدون ایجاد تداخل با عامل همکار ثبت می‌کند.

خانواده مرجع

پس از گذار به SQLite، رونوشت‌های نشست فعال ردیف‌های SQLite هستند. خانواده بایگانی یک نشست عبارت است از:

• ردیف‌های transcript_events، transcript_event_identities و sessions برای sessionId فعلی ورودی.
• همان مجموعه ردیف رونوشت SQLite برای هر sessionId که entry.compactionCheckpoints[*].preCompaction.sessionId به آن ارجاع می‌دهد.
• همان مجموعه ردیف رونوشت SQLite برای هر sessionId که entry.compactionCheckpoints[*].postCompaction.sessionId به آن ارجاع می‌دهد.
• همان مجموعه ردیف رونوشت SQLite برای هر sessionId در entry.usageFamilySessionIds.

فقط ردیف‌هایی را بایگانی کنید که دیگر هیچ ردیف باقی‌مانده session_entries یا فراداده Compaction یا خانواده مصرف هیچ ورودی باقی‌مانده‌ای به آن‌ها ارجاع نمی‌دهد. این کار وضعیت شاخه/بازیابی نقطه بررسی و تجمیع مصرف را تا حذف آخرین ارجاع زنده حفظ می‌کند.

مصنوعات خارج از خانواده پس از گذار

گونه‌های فایل رونوشت موضوعی تولیدشده و فایل‌های جانبی مسیر حرکت، وضعیت فعال زمان اجرای SQLite نیستند. آن‌ها مصنوعات فایل قدیمی هستند:

• گونه‌های موضوعی مانند <sessionId>-topic-<thread>.jsonl فقط برای قالب رونوشت مبتنی بر فایل وجود دارند. SQLite به‌جای فایل‌های JSONL جداگانه برای هر موضوع، از شناسه متعارف نشست به‌همراه فراداده تحویل session_routes/ورودی استفاده می‌کند.
• فایل‌های جانبی مسیر حرکت مانند .trajectory.jsonl و .trajectory-path.json بر اساس مسیرهای واقعی JSONL در sessionFile نام‌گذاری می‌شوند. مقادیر sessionFile در SQLite نشانگرهای sqlite:<agentId>:<sessionId>:<storePath> هستند و فایل‌های جانبی را نام‌گذاری نمی‌کنند.
• خوانندگان سطح بایگانی باید همچنان فایل‌های JSONL قدیمی بایگانی‌شده را بخوانند، اما نگهداشت زمان اجرا نباید پوشه‌های نشست فعال را پیمایش کند یا فایل‌های رونوشت JSONL را برای نشست‌های SQLite دوباره باز کند.

واردسازی Doctor همچنان مالک مهاجرت فایل‌های اصلی JSONL قدیمی و فایل‌های جانبی مسیر حرکت مجاور آن‌ها است. نگهداشت SQLite در زمان اجرا نباید واردکننده دوم یا مسیر جایگزین فایل اضافه کند.

نقاط وصله

تابع کمکی بایگانی SQLite معرفی‌شده توسط clawdbot-d63.1 را گسترش دهید و مسیر موازی اضافه نکنید.

1. یک گردآورنده محلی نزدیک deleteSqliteSessionStateIfUnreferenced اضافه کنید:

   • collectSqliteSessionArtifactFamily(entry: SessionEntry): Set<string>
   • entry.sessionId، شناسه‌های نشست پیش/پس از نقطه بررسی و usageFamilySessionIds را شامل کنید.
   • رشته‌های خالی را فیلتر و به‌صورت قطعی موارد تکراری را حذف کنید.

2. یک گردآورنده ارجاع برای مخزن پس از حذف اضافه کنید:

   • readReferencedSqliteSessionArtifactFamilyIds(database): Set<string>
   • session_entries فعلی را پیمایش، هر entry_json را تجزیه و همان شناسه‌های خانواده را از هر ورودی باقی‌مانده گردآوری کنید.

3. فراخوان‌هایی را که برای بازنشانی/حذف/نگهداشت اکنون یک sessionId حذف‌شده را بایگانی می‌کنند، تغییر دهید تا خانواده کامل ورودی حذف‌شده را ارسال کنند.

4. برای هر شناسه خانواده، ردیف‌های رونوشت SQLite را با دلیل فراخوان (reset یا deleted) بایگانی کنید، سپس ردیف sessions را فقط زمانی حذف کنید که شناسه خانواده در مجموعه ارجاع پس از حذف وجود نداشته باشد.

5. حذف رویدادهای رونوشت را از طریق مسیر پاک‌سازی موجود ردیف نشست SQLite متمرکز نگه دارید. خواندن فعال JSONL اضافه نکنید.

آزمون‌های متمرکز

آزمون‌های مختص SQLite را به src/config/sessions/session-accessor.conformance.test.ts یا پس از ثبت تغییرات clawdbot-d63.1 به آزمون چرخه عمر همکار اضافه کنید:

• حذف ورودی دارای رونوشت پیش از Compaction، هم نشست فعلی و هم نشست پیش از Compaction را بایگانی می‌کند و سپس هر دو مجموعه ردیف SQLite را حذف می‌کند.
• حذف یکی از دو ورودی که یک نشست پیش از Compaction مشترک دارند، تا زمان حذف آخرین ورودی ارجاع‌دهنده چیزی را برای نشست پیشین مشترک بایگانی نمی‌کند.
• حذف ورودی دارای usageFamilySessionIds، هنگامی‌که هیچ ورودی دیگری به آن خانواده مصرف ارجاع نمی‌دهد، ردیف‌های رونوشت SQLite مربوط به پیشینیان را بایگانی می‌کند.
• یک کلید نشست با ساختار موضوع و نشانگر SQLite باعث هیچ‌گونه خواندن JSONL موضوعی تولیدشده یا جست‌وجوی فایل جانبی نمی‌شود.

برای اثبات متمرکز باید از این دستور استفاده شود:

node scripts/run-vitest.mjs src/config/sessions/session-accessor.conformance.test.ts

اگر آزمون‌های نهایی در store.session-lifecycle-mutation.test.ts قرار دارند، آن فایل را صریحاً با همان اجراکننده اجرا کنید. درخت‌کاری‌های گسترده pnpm باید برای این محیط کاری Codex روی Crabbox/Testbox باقی بمانند.