هارنس زندهٔ E2E برای SQLite در مسیر 3

مهار E2E زنده SQLite در مسیر 3 ثابت می‌کند که Gateway از SQLite به‌عنوان مخزن مرجع نشست و رونوشت استفاده می‌کند، درحالی‌که فایل‌های قدیمی JSONL همچنان ورودی مهاجرت یا محتوای بایگانی باقی می‌مانند. این یک مهار اثبات برای نگه‌دارندگان است، نه یک ابزار عیب‌یابی معمول برای کاربران.

پس از آن‌که Gateway ترافیک پس از مهاجرت را پردازش کرد، برابری با JSONL قدیمی دیگر سیگنال معتبری برای سلامت زمان اجرا نیست. یک Gateway مهاجرت‌یافته سالم ممکن است ردیف‌های رونوشت SQLite داشته باشد که با تعدادهای JSONL قدیمی متفاوت‌اند، زیرا نوبت‌های جدید باید فقط SQLite را پیش ببرند. بنابراین مهار زنده باید رفتار Gateway، تغییر ردیف‌های SQLite، سکون فایل‌های قدیمی و سلامت گزارش‌ها را در هر مرحله اندازه‌گیری کند.

شکل فرمان

فرمان زنده موردنظر چنین است:

node scripts/path3-live-sqlite-e2e.mjs \  --url http://127.0.0.1:18789 \  --agent main \  --session-key agent:main:path3-live-e2e:<timestamp> \  --json

این فرمان به یک Gateway از قبل در حال اجرا متصل می‌شود. Gateway را راه‌اندازی یا متوقف نمی‌کند و مهاجرت را وارد یا دوباره اجرا نمی‌کند، مگر آن‌که بعداً یک حالت صریح مهاجرت افزوده شود. یک گونه CI یا محلیِ ایزوله می‌تواند از test/helpers/openclaw-test-instance.ts استفاده کند، اما مسیر اثبات زنده باید Gateway واقعی اپراتور و پایگاه داده واقعی SQLite هر عامل آن را بررسی کند.

اثبات ایزوله CLI ساخته‌شده

اجراکننده اثبات CLI ساخته‌شده، یک مخزن نشست قدیمی ایزوله را مقداردهی اولیه می‌کند، Gateway بازسازی‌شده را راه‌اندازی می‌کند و ثابت می‌کند که راه‌اندازی، نشست‌های قدیمی فعال را پیش از آغاز خواندن‌های زمان اجرا به SQLite وارد می‌کند. این اجراکننده نباید پیش از نخستین راه‌اندازی Gateway، openclaw doctor --fix را اجرا کند، زیرا در آن صورت به‌جای مسیر ارتقایی که کاربران در نخستین راه‌اندازی پس از تغییر دریافت می‌کنند، مسیر مهاجرت دستی اثبات می‌شود.

پس از واردسازی هنگام راه‌اندازی، اثبات ایزوله می‌تواند openclaw doctor --session-sqlite inspect و openclaw doctor --session-sqlite validate را به‌عنوان شواهد عیب‌یابی اجرا کند. این فرمان‌های doctor محرک مهاجرت برای اثبات ارتقا هنگام راه‌اندازی نیستند. سناریوهای جداگانه واردسازی doctor باید فایل‌های رونوشت قدیمی را همراه با فایل‌های جانبی مسیر حرکت مقداردهی اولیه کنند و تأیید کنند که doctor آن مصنوعات را بایگانی می‌کند، درحالی‌که SQLite مرجع باقی می‌ماند.

پیش‌بررسی

پیش‌بررسی یک خط مبنا گردآوری می‌کند و اگر Gateway قابل‌استفاده نباشد، پیش از ارسال نوبت اثبات شکست می‌خورد:

• GET /health و وضعیت عمیق Gateway باید یک Gateway در حال اجرا و قابل‌دسترسی را گزارش کنند.
• نسخه‌های CLI و Gateway باید با شاخه در حال آزمایش مطابقت داشته باشند.
• مهار یک مکان‌نمای گزارش برای فایل گزارش فعال Gateway ثبت می‌کند.
• مهار تعداد ردیف‌های جدول SQLite هر عامل را برای sessions، session_entries، transcript_events، transcript_event_identities و session_routes ثبت می‌کند.
• مهار mtime، size و وضعیت وجود را برای sessions.json قدیمی، فایل‌های JSONL ارجاع‌شده و مسیرهای احتمالی JSONL نشست اثبات ثبت می‌کند.
• lsof -p <gateway-pid> باید دسته‌های SQLite DB/WAL/SHM را نشان دهد و هیچ دسته فعال .jsonl یا sessions.json را نشان ندهد.

openclaw doctor --session-sqlite validate در حالت زنده صرفاً اطلاع‌رسانی است. پس از ترافیک بعد از تغییر، ممکن است واگرایی موردانتظار نسبت به فایل‌های قدیمی را گزارش کند. مهار باید از خروجی doctor برای طبقه‌بندی و فهرست‌برداری مهاجرت استفاده کند، نه به‌عنوان مرجع قبولی/رد زمان اجرا.

سناریوی عامل‌محور

سناریوی زنده از یک کلید نشست اختصاصی اثبات استفاده می‌کند و تا حد امکان Gateway را از طریق مسیرهای عمومی RPC هدایت می‌کند. یک نوبت عامل باید برای اعمال ماندگاری معمول کافی باشد، اما اثبات کامل باید درزهای 3.1b را پوشش دهد که پیش‌تر به بررسی‌های زنده جداگانه نیاز داشتند:

• نوبت گفت‌وگوی معمول: نشست اثبات را ایجاد یا دوباره استفاده کنید، یک درخواست واقعی عامل بفرستید، منتظر نتیجه نهایی دستیار بمانید و chat.history یا تصویر معادل Gateway را تأیید کنید.
• هویت رونوشت: تأیید کنید همان نشانگر در تاریخچه Gateway و در ردیف‌های رونوشت SQLite، از جمله ردیف‌های هویت پایدار رویداد در صورت وجود، ظاهر می‌شود.
• دسترسی‌دهنده‌های فراداده نشست: نشست اثبات و نشست‌های زنده موجود منتخب را از طریق دسترسی‌دهنده‌های Gateway/نشست بخوانید و آن‌ها را با ردیف‌های SQLite مقایسه کنید.
• تصویر وصله نشست: یک تغییر برگشت‌پذیر در فراداده مدل/نشست روی نشست اثبات اعمال کنید، سپس تأیید کنید ردیف تصویرشده و پاسخ Gateway یکسان‌اند.
• چرخه عمر نقطه بررسی Compaction: فقط روی نشست اثبات یا یک نشست نمونه مصنوعی ایجادشده توسط مهار، یک نقطه بررسی را فهرست، منشعب و بازیابی کنید.
• بازیابی پس از راه‌اندازی مجدد: مسیر امن نشانگر بازیابی را روی یک نشست اثبات کنترل‌شده یا یک نمونه آزمایشی ایزوله اجرا کنید؛ حالت زنده فقط زمانی می‌تواند این مرحله را اجرا کند که مجموعه نشست هدف صریح و برگشت‌پذیر باشد.
• چرخه عمر پاک‌سازی: نشست اثبات را حذف یا بازنشانی کنید، سپس ردیف‌های چرخه عمر SQLite و وضعیت بایگانی‌شده رونوشت را تأیید کنید.

درزهای ویژه انتقال که نمی‌توان آن‌ها را با ایمنی روی Gateway زنده اپراتور اعمال کرد، مانند ورودی WhatsApp یا تماس صوتی، باید به‌جای جعل انتقال خارجی از کاوشگرهای زمان اجرای سطح مالک در برابر همان قرارداد SQLite استفاده کنند.

بررسی‌های هر مرحله

هر مرحله وضعیت پیش و پس از خود را ثبت می‌کند و یک رکورد بررسی ساخت‌یافته می‌نویسد:

• تعداد ردیف‌های SQLite فقط در محل‌های موردانتظار افزایش می‌یابد.
• ردیف‌های زمان اجرای مسیر حرکت برای نشست‌های اثبات مبتنی بر نشانگر که رویدادهای زمان اجرا را ثبت می‌کنند، افزایش می‌یابند.
• ردیف نشست اثبات دارای session_id، وضعیت، مُهرهای زمانی، فراداده و ردیف‌های مسیر موردانتظار است.
• تصویر تاریخچه/نشست Gateway با انتهای رونوشت SQLite مطابقت دارد.
• هیچ فایل JSONL برای نشست اثبات ایجاد یا تغییر داده نمی‌شود.
• هیچ فایل جانبی .trajectory.jsonl، .trajectory-path.json یا trajectory/<session>.jsonl مشتق‌شده از نشانگر برای نشست اثبات ایجاد نمی‌شود.
• فایل‌های JSONL قدیمی موجود و sessions.json بدون تغییر باقی می‌مانند، مگر آن‌که مرحله صراحتاً یک عملیات مهاجرت آفلاین یا بایگانی باشد.
• فرایند Gateway دسته‌های .jsonl یا sessions.json را باز نمی‌کند.
• گزارش‌ها از مکان‌نمای قبلی شامل هیچ ERROR، FATAL، SQLITE_، no such column، عدم دسترسی به مخزن نشست، شکست بازیابی پس از راه‌اندازی مجدد یا هشدار تطبیق رونوشت نیستند، مگر آن‌که سناریو صراحتاً آن را در فهرست مجاز قرار دهد.

پویش گزارش بخشی از قرارداد قبولی/رد است. Gatewayای که به بررسی‌های سلامت پاسخ می‌دهد اما خطاهای طرح‌واره SQLite یا شکست‌های تکراری تطبیق رونوشت منتشر می‌کند، برای مسیر 3 سبز نیست.

مصنوع اثبات

مهار باید شواهد را در .artifacts/path3-live-e2e/<timestamp>/ بنویسد و آن را خارج از git نگه دارد:

• summary.json: آرگومان‌های فرمان، نسخه Gateway، نتیجه، بررسی ناموفق و مسیرهای مصنوعات.
• sqlite-before.json و sqlite-after.json: تعداد ردیف‌ها و ردیف‌های منتخب اثبات.
• legacy-files.json: وجود فایل قدیمی، mtime، اندازه و این‌که آیا هر فایل تغییر کرده است.
• gateway-log-scan.json: بازه مکان‌نما، خطوط گزارش منطبق و تصمیم‌های فهرست مجاز.
• events.jsonl: مشاهدات مرتب هر مرحله، مناسب برای دیدگاه‌های اثبات PR.

اثبات PR باید این مصنوعات را خلاصه کند، نه این‌که رونوشت‌های کامل یا محتوای پیام‌های خصوصی را جای‌گذاری کند.

قواعد ایمنی

• حالت زنده هرگز نباید در زمان اجرای Gateway، JSONL قدیمی را دوباره وارد کند.
• حالت زنده نباید نشست‌های غیراثبات را تغییر دهد، مگر برای کاوش‌های ترمیمی صریحاً انتخاب‌شده و برگشت‌پذیر.
• هر مرحله مخرب یا گسترده مهاجرت به یک پشتیبان تازه از پایگاه داده SQLite و پوشه نشست قدیمی تحت تأثیر نیاز دارد.
• پشتیبان‌ها باید به پایگاه داده عامل/پوشه نشست دست‌خورده محدود باشند و طی یک اجرای اثبات دوباره استفاده شوند تا از رشد نامحدود دیسک جلوگیری شود.
• مرحله پاک‌سازی نباید هیچ نشست اثبات، JSONL اثبات یا فایل قدیمی تغییرکرده‌ای باقی بگذارد، مگر آن‌که فراخواننده --keep-artifacts را ارسال کند.

نتیجه موفق

اجرای زنده موفق یعنی Gateway یک جریان واقعی نشست عامل‌محور را پذیرفته، تمام وضعیت مرجع مشاهده‌شده در SQLite بوده، فایل‌های زمان اجرای قدیمی ساکن مانده‌اند و سلامت گزارش در بازه اندازه‌گیری‌شده پاک باقی مانده است. این به این معنا نیست که برابری JSONL قدیمی پس از ترافیک زنده همچنان پاک می‌ماند؛ هنگامی‌که SQLite مخزن مرجع باشد، واگرایی زنده موردانتظار است.