---
read_when:
    - आप लाइव Gateway के विरुद्ध Path 3 SQLite स्टोरेज परिवर्तन को प्रमाणित कर रहे हैं
    - आपको अपेक्षित विरासती JSONL विचलन को रनटाइम विफलताओं से अलग पहचानना होगा
    - आप एजेंट-संचालित लाइव SQLite E2E हार्नेस बना रहे हैं या उसकी समीक्षा कर रहे हैं
summary: Path 3 SQLite सत्र/ट्रांसक्रिप्ट बदलाव के लाइव Gateway प्रमाण की रूपरेखा
title: पथ 3 लाइव SQLite E2E हार्नेस
x-i18n:
    generated_at: "2026-07-19T09:37:27Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: 2749bf47cb4967bc80a5ed37a12f2a553f3b388ed8cd90cfb3217e1b5e8afae9
    source_path: reference/path3-live-sqlite-e2e-harness.md
    workflow: 16
---

Path 3 लाइव SQLite E2E हार्नेस यह प्रमाणित करता है कि Gateway, SQLite का
प्रामाणिक सत्र और ट्रांसक्रिप्ट स्टोर के रूप में उपयोग कर रहा है, जबकि पुराने JSONL फ़ाइलें
माइग्रेशन इनपुट या संग्रह सामग्री बनी रहती हैं। यह अनुरक्षक प्रमाण हार्नेस है, कोई
सामान्य उपयोगकर्ता निदान नहीं।

Gateway द्वारा माइग्रेशन के बाद का ट्रैफ़िक संसाधित कर लेने के बाद, पुराने JSONL की समानता
रनटाइम स्वास्थ्य का वैध संकेत नहीं रहती। एक स्वस्थ माइग्रेट किया गया Gateway में
SQLite ट्रांसक्रिप्ट पंक्तियाँ पुराने JSONL की गणनाओं से भिन्न हो सकती हैं, क्योंकि नए टर्न
केवल SQLite को आगे बढ़ाने चाहिए। इसलिए लाइव हार्नेस को प्रत्येक
चरण पर Gateway व्यवहार, SQLite पंक्तियों में बदलाव, पुरानी फ़ाइलों की निष्क्रियता और लॉग स्वास्थ्य
मापना चाहिए।

## कमांड का स्वरूप

अभीष्ट लाइव कमांड है:

```bash
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 से जुड़ता है। यह माइग्रेशन को प्रारंभ, बंद,
इंपोर्ट या दोबारा नहीं चलाता, जब तक कि बाद में कोई स्पष्ट माइग्रेशन मोड न जोड़ा जाए।
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 फ़ाइल लॉग के लिए एक लॉग कर्सर रिकॉर्ड करता है।
- हार्नेस `sessions`,
  `session_entries`, `transcript_events`, `transcript_event_identities`, और
  `session_routes` के लिए प्रति-एजेंट SQLite तालिका गणनाएँ रिकॉर्ड करता है।
- हार्नेस पुराने
  `sessions.json`, संदर्भित JSONL फ़ाइलों और संभावित प्रमाण-सत्र JSONL
  पथों के लिए `mtime`, `size` और अस्तित्व रिकॉर्ड करता है।
- `lsof -p <gateway-pid>` को SQLite DB/WAL/SHM हैंडल दिखाने चाहिए और कोई सक्रिय
  `.jsonl` या `sessions.json` हैंडल नहीं दिखाना चाहिए।

लाइव मोड में `openclaw doctor --session-sqlite validate` केवल सूचनात्मक है।
बदलाव के बाद के ट्रैफ़िक के उपरांत यह पुरानी फ़ाइलों के मुकाबले अपेक्षित अंतर रिपोर्ट कर सकता है।
हार्नेस को वर्गीकरण और माइग्रेशन इन्वेंटरी के लिए doctor आउटपुट का उपयोग करना चाहिए,
न कि रनटाइम पास/फ़ेल निर्णायक के रूप में।

## एजेंट-संचालित परिदृश्य

लाइव परिदृश्य एक समर्पित प्रमाण सत्र कुंजी का उपयोग करता है और जहाँ भी संभव हो,
सार्वजनिक RPC पथों के माध्यम से Gateway चलाता है। सामान्य स्थायित्व का अभ्यास करने के लिए
एक एजेंट टर्न पर्याप्त होना चाहिए, लेकिन पूर्ण प्रमाण को उन 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 स्कीमा त्रुटियाँ या बार-बार ट्रांसक्रिप्ट पुनर्मिलान विफलताएँ उत्सर्जित करता है,
Path 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 DB और पुराने सत्र डायरेक्टरी का नया बैकअप आवश्यक है।
- बैकअप को प्रभावित एजेंट DB/सत्र डायरेक्टरी तक सीमित रखना चाहिए और असीमित डिस्क वृद्धि से बचने के लिए
  एक प्रमाण रन के दौरान पुनः उपयोग करना चाहिए।
- सफ़ाई चरण के बाद कोई प्रमाण सत्र, प्रमाण JSONL या संशोधित पुरानी
  फ़ाइल शेष नहीं रहनी चाहिए, जब तक कि कॉलर `--keep-artifacts` पास न करे।

## सफल परिणाम

एक सफल लाइव रन का अर्थ है कि Gateway ने वास्तविक एजेंट-संचालित सत्र प्रवाह स्वीकार किया,
सभी अवलोकित प्रामाणिक स्थितियाँ SQLite में थीं, पुरानी रनटाइम फ़ाइलें
निष्क्रिय रहीं और मापी गई अवधि में लॉग स्वास्थ्य साफ़ रहा। इसका यह अर्थ नहीं है कि
लाइव ट्रैफ़िक के बाद पुराने JSONL की समानता साफ़ बनी रहती है; SQLite के प्रामाणिक स्टोर
बनते ही लाइव अंतर अपेक्षित है।