सबूत
कोई भी दावा कर सकता है कि bug ठीक हो गया है। यह पेज fix दिखाता है, वह test जो उसकी रखवाली करता है, और यह सबूत कि bug लौटने पर test fail होता है।
tools/prove_regressions.py से 2026-10-03 को जनरेट किया गया · 4 में से 4 रिग्रेशन टेस्ट non-vacuous (खोखले नहीं) साबित हुए।
हर प्रमाण कैसे तैयार होता है
- fixed code पर regression test चलाएँ: इसे pass होना चाहिए।
- मूल बग को वापस लाने के लिए सोर्स संपादित करें।
- वही टेस्ट फिर से चलाइए: इसे असली assertion failure के साथ फ़ेल होना चाहिए। कलेक्शन एरर गिनी नहीं जाती: उसका मतलब है कि टेस्ट कभी चला ही नहीं।
- फ़ाइल वापस रखें, जाँचें कि उसका SHA-256 मूल से मेल खाता है, और फिर से चलाएँ: इसे फिर से पास होना चाहिए।
असिस्टेंट ने विज़िटरों को बताया कि webhook उनकी बातचीत ले जाता है। वह उसका कुछ भी नहीं ले जाता।
commit e027e6b · apps/gateway/tests/test_webhook_content_claim.py द्वारा सुरक्षित
Webhook payloads जानबूझकर किसी टर्न का केवल आकार (SHAPE) ले जाते हैं: event name, timestamp, step count, credits, और कभी उसकी सामग्री नहीं। असिस्टेंट से पूछा गया कि क्या webhooks में बातचीत शामिल होती है, तो उसने जवाब दिया 'हाँ: हर webhook payload में उस टर्न का पूरा conversation history शामिल होता है।' यह ठीक उस गारंटी का उल्टा है जिसके विरुद्ध allow-list का परीक्षण किया जाता है। फ़िक्स से पहले 6 रन में 2 मनगढ़ंत उत्तर मापे गए।
| ठीक किया गया कोड, टेस्ट रन |
पास |
21 passed in 1.15s |
| Bug वापस डाला गया, वही test |
पकड़ा गया |
8 failed, 13 passed in 1.20s |
| फ़ाइल वापस रखी गई, टेस्ट चलता है |
पास |
sha256 a8d4cb0b10787eff… |
यह टेस्ट non-vacuous है: bug लौटने पर यह फेल हो जाता है।
हमने मालिकों से एक ऐसे डैशबोर्ड कार्ड पर क्लिक करने को कहा जो मौजूद ही नहीं है।
कमिट b4a203a · apps/gateway/tests/test_card_names.py द्वारा सुरक्षित
नॉलेज बेस, डॉक्स और एक स्टार्टर टाइल, तीनों ने मालिकों को 'Send turns to a webhook' नाम का कार्ड ढूँढने को कहा। असली डैशबोर्ड कार्ड पर 'Send events to your own system' लिखा है। यह नाम नॉलेज सेक्शन लिखते समय गढ़ा गया था और बिना जाँच के तीन जगहों पर फैल गया। मापा गया: 2 में से 2 सेटअप उत्तरों ने एक ऐसे कंट्रोल का नाम लिया जो कभी अस्तित्व में ही नहीं था।
| ठीक किया गया कोड, टेस्ट रन |
पास |
5 passed in 1.12s |
| Bug वापस डाला गया, वही test |
पकड़ा गया |
3 failed, 2 passed in 1.23s |
| फ़ाइल वापस रखी गई, टेस्ट चलता है |
पास |
sha256 f6348e1a5bbae209… |
यह टेस्ट non-vacuous है: bug लौटने पर यह फेल हो जाता है।
डार्क-मोड अभिवादन 1.73:1 पर रेंडर हुआ, जो लगभग अदृश्य था, और गार्ड इसे पकड़ ही नहीं सकता था।
कमिट ca47f41 · apps/studio/test/themeContrast.test.mjs द्वारा सुरक्षित
किसी टेस्ट से नहीं, बल्कि एक असली iPhone पर लिए गए स्क्रीनशॉट से पकड़ा गया। स्वागत अभिवादन #3a3a3c पर हार्डकोड था, जो डार्क-मोड पैनल के सामने 1.73:1 पर है: 4.5:1 की न्यूनतम सीमा से बहुत नीचे और मुश्किल से पढ़ने लायक। डार्क मोड में आने वाले हर पहली बार के विज़िटर ने इसे देखा। फ़िक्स रंग को थीम वेरिएबल --pw-mist से होकर ले जाता है ताकि यह पैनल के अनुसार चले; गार्ड अब यह मान लेने के बजाय कि रंग सेट किया गया था, हर थीम वाली जोड़ी का वास्तविक कॉन्ट्रास्ट अनुपात गणना करता है।
| ठीक किया गया कोड, टेस्ट रन |
पास |
pass 5, fail 0 |
| Bug वापस डाला गया, वही test |
पकड़ा गया |
pass 3, fail 2 |
| फ़ाइल वापस रखी गई, टेस्ट चलता है |
पास |
sha256 54f8802b444b6194… |
यह टेस्ट non-vacuous है: bug लौटने पर यह फेल हो जाता है।
एक विफल टर्न की वजह से विज़िटर एक मृत स्ट्रीम पर हमेशा इंतज़ार करता रह जाता था।
कमिट 4bcc691 · apps/studio/test/streamError.test.mjs द्वारा सुरक्षित
जब model call विफल हुई, तो server ने सही ढंग से एक error frame भेजा, लेकिन widget ने संदेश को एक ऐसे element में लिखा जिसे governance-trace branch पहले ही छिपा चुकी थी, और trace को कभी collapse नहीं किया। visitor को एक ऐसे turn पर 'Reading your message' अनिश्चित काल तक टिमटिमाता दिखा जो पहले ही विफल हो चुका था: न कोई error, न कोई recovery, न जानने का कोई तरीका। error text सही ढंग से assign हुआ था, पर कहीं भी दिखाया नहीं गया। यह एक असली outage के दौरान मिला, जब API account का credit ख़त्म हो गया था।
| ठीक किया गया कोड, टेस्ट रन |
पास |
pass 4, fail 0 |
| Bug वापस डाला गया, वही test |
पकड़ा गया |
pass 2, fail 2 |
| फ़ाइल वापस रखी गई, टेस्ट चलता है |
पास |
sha256 54f8802b444b6194… |
यह टेस्ट non-vacuous है: bug लौटने पर यह फेल हो जाता है।
परिचालन रिकॉर्ड
प्लेटफ़ॉर्म के पीछे क्या मौजूद है, और क्या बिना टेस्ट किया हुआ है। केवल वही जो कोई स्क्रिप्ट या लॉग दिखा सके।
- बैकअप: हर रात 03:17 UTC, pg_dump --clean --if-exists, gzip; हर रन के बाद एक private git remote पर push किया जाता है; नवीनतम
20261003T031701Z; 29 dumps रखे जाते हैं।
- रिस्टोर ड्रिल 2026-10-03: dump
20261003T031701Z को उसी होस्ट पर एक अस्थायी pgvector/pgvector:pg16 कंटेनर में 2 s में रिस्टोर किया गया: 34 tenants, 270 knowledge पंक्तियाँ, 47 टेबल। dump 03:17 UTC का है; 13:26 UTC पर निर्धारित demo cleanup ने 30 दिन से पुराना एक छोड़ा हुआ demo tenant हटा दिया (gateway लॉग), इसलिए रिस्टोर में ड्रिल के समय लाइव की तुलना में एक tenant अधिक दिखता है।
- रोलबैक: साइट: tools/deploy-site.sh --rollback (पिछली release पर एक दूसरा symlink flip); Studio: tools/deploy-studio.sh --rollback (पिछली image, health-check के साथ)।
- रिकवरी लक्ष्य: कोई वादा नहीं। रात का dump डेटा हानि को एक दिन तक सीमित करता है; रिस्टोर का कोई तय समय नहीं बताया गया।
- बिना टेस्ट किए: एक instance से अधिक लोड; multi-region failover; किसी अलग होस्ट पर रिस्टोर।
docs/ops-record.json से, जिसे रिस्टोर ड्रिल (docs/runbooks/db-backup.md) ने लिखा।
यह क्या सिद्ध नहीं करता
ये मेरे अपने कोड पर खुद चलाई गई जाँचें हैं। ये दिखाती हैं कि ख़ास टेस्ट ख़ास बग पकड़ते हैं: यह नहीं कि सिस्टम दूसरे बगों से मुक्त है, यह नहीं कि ऑडिट व्यापक थे, और यह नहीं कि किसी स्वतंत्र व्यक्ति ने इसकी समीक्षा की है। harness रिपॉज़िटरी में है; दावे को उसे चलाकर जाँचा जा सकता है।
PANTHEON · साबित करें, लाइव सिस्टम पर हमला करें · ऑडिट रिकॉर्ड · वॉकथ्रू · काम · CV
यहाँ किसी भी दोष के बारे में पूछें, और यह भी कि उसका टेस्ट सुधार को कैसे साबित करता है।
- मुझे एक असली बग दिखाएँ जो उन्होंने खोजा और ठीक किया
- आप कैसे जानते हैं कि कोई टेस्ट विफल हो सकता है?
- अभी क्या खुला है?