ثبوت
کوئی بھی دعویٰ کر سکتا ہے کہ bug ٹھیک ہو گیا ہے۔ یہ صفحہ fix دکھاتا ہے، وہ ٹیسٹ جو اس کی حفاظت کرتا ہے، اور یہ ثبوت کہ bug واپس آنے پر ٹیسٹ fail ہو جاتا ہے۔
2026-10-03 کو tools/prove_regressions.py سے تیار کیا گیا · 4 میں سے 4 ریگریشن ٹیسٹ غیر خالی ثابت ہوئے۔
ہر ثبوت کیسے تیار ہوتا ہے
- regression test کو درست کیے گئے code پر چلائیں: اسے pass ہونا چاہیے۔
- اصل bug دوبارہ لانے کے لیے سورس میں ترمیم کریں۔
- وہی ٹیسٹ دوبارہ چلائیں: اسے ناکام ہونا چاہیے، ایک حقیقی assertion failure کے ساتھ۔ collection error شمار نہیں ہوتا: اس کا مطلب ہے کہ ٹیسٹ کبھی چلا ہی نہیں۔
- فائل بحال کریں، تصدیق کریں کہ اس کا SHA-256 اصل سے مطابقت رکھتا ہے، اور دوبارہ چلائیں: اسے دوبارہ پاس ہونا چاہیے۔
اسسٹنٹ نے وزیٹرز کو بتایا کہ webhook ان کی گفتگو لے جاتا ہے۔ وہ اس میں سے کچھ بھی نہیں لے جاتا۔
کمٹ e027e6b · محفوظ بذریعہ apps/gateway/tests/test_webhook_content_claim.py
Webhook payloads جان بوجھ کر ایک ٹرن کی صرف ساخت (SHAPE) رکھتے ہیں: ایونٹ کا نام، ٹائم اسٹیمپ، اسٹیپس کی تعداد، کریڈٹس، اور کبھی اس کا مواد نہیں۔ اسسٹنٹ سے پوچھا گیا کہ کیا webhooks میں گفتگو شامل ہوتی ہے، تو اس نے جواب دیا 'ہاں، ہر webhook payload میں اس ٹرن کی مکمل گفتگو کی تاریخ شامل ہوتی ہے۔' یہ اس ضمانت کے بالکل الٹ ہے جس کے خلاف allow-list کو ٹیسٹ کیا جاتا ہے۔ فکس سے پہلے 6 رنز میں 2 من گھڑت جوابات ناپے گئے۔
| طے شدہ کوڈ، ٹیسٹ رنز |
کامیاب |
21 passed in 1.15s |
| Bug دوبارہ داخل، وہی ٹیسٹ |
پکڑا گیا |
8 failed, 13 passed in 1.20s |
| فائل بحال، ٹیسٹ چلتا ہے |
کامیاب |
sha256 a8d4cb0b10787eff… |
یہ ٹیسٹ بے معنی نہیں: بگ واپس آئے تو یہ فیل ہو جاتا ہے۔
ہم نے مالکان سے ایک ایسے ڈیش بورڈ کارڈ پر کلک کرنے کو کہا جو موجود ہی نہیں۔
کمٹ b4a203a · apps/gateway/tests/test_card_names.py کے ذریعے محفوظ
نالج بیس، ڈاکس اور ایک starter tile، سب نے مالکان کو 'Send turns to a webhook' نامی کارڈ تلاش کرنے کو کہا۔ اصل ڈیش بورڈ کارڈ پر 'Send events to your own system' لکھا ہے۔ یہ نام اس وقت گھڑا گیا جب knowledge سیکشن لکھا گیا، اور بغیر جانچ کے تین جگہوں تک پھیل گیا۔ پیمائش: 2 میں سے 2 سیٹ اپ جوابات نے ایک ایسے کنٹرول کا نام لیا جو کبھی موجود ہی نہیں تھا۔
| طے شدہ کوڈ، ٹیسٹ رنز |
کامیاب |
5 passed in 1.12s |
| Bug دوبارہ داخل، وہی ٹیسٹ |
پکڑا گیا |
3 failed, 2 passed in 1.23s |
| فائل بحال، ٹیسٹ چلتا ہے |
کامیاب |
sha256 f6348e1a5bbae209… |
یہ ٹیسٹ بے معنی نہیں: بگ واپس آئے تو یہ فیل ہو جاتا ہے۔
ڈارک موڈ والا خوش آمدیدی پیغام 1.73:1 پر رینڈر ہوا، عملاً نظر نہ آنے والا، اور گارڈ اسے پکڑ ہی نہیں سکتا تھا۔
کمٹ ca47f41 · apps/studio/test/themeContrast.test.mjs کے ذریعے محفوظ
یہ کسی ٹیسٹ سے نہیں، بلکہ ایک حقیقی iPhone پر لیے گئے اسکرین شاٹ سے پکڑا گیا۔ خوش آمدیدی پیغام کا رنگ #3a3a3c پر hardcode تھا، جو ڈارک موڈ پینل کے مقابلے میں 1.73:1 بنتا ہے، 4.5:1 کی کم از کم حد سے بہت نیچے اور بمشکل پڑھنے کے قابل۔ ڈارک موڈ میں ہر پہلی بار آنے والے نے اسے دیکھا۔ اصلاح رنگ کو تھیم variable --pw-mist کے ذریعے لے جاتی ہے تاکہ یہ پینل کے مطابق رہے؛ guard اب یہ بھروسہ کرنے کے بجائے کہ رنگ سیٹ کیا گیا تھا، ہر تھیم والے جوڑے کا اصل contrast ratio حساب کرتا ہے۔
| طے شدہ کوڈ، ٹیسٹ رنز |
کامیاب |
pass 5, fail 0 |
| Bug دوبارہ داخل، وہی ٹیسٹ |
پکڑا گیا |
pass 3, fail 2 |
| فائل بحال، ٹیسٹ چلتا ہے |
کامیاب |
sha256 54f8802b444b6194… |
یہ ٹیسٹ بے معنی نہیں: بگ واپس آئے تو یہ فیل ہو جاتا ہے۔
ایک ناکام ٹرن نے وزیٹر کو ایک مردہ stream پر ہمیشہ کے لیے انتظار میں چھوڑ دیا۔
کمٹ 4bcc691 · apps/studio/test/streamError.test.mjs کے ذریعے محفوظ
جب ماڈل کال ناکام ہوئی تو سرور نے درست طور پر ایک error frame بھیجا، لیکن widget نے پیغام ایک ایسے element میں لکھ دیا جسے governance-trace branch پہلے ہی چھپا چکی تھی، اور trace کو کبھی collapse نہیں کیا۔ وزیٹر کو ایک ایسے turn پر جو پہلے ہی ناکام ہو چکا تھا 'Reading your message' غیر معینہ مدت تک دھڑکتا نظر آیا: نہ کوئی error، نہ کوئی recovery، نہ جاننے کا کوئی طریقہ۔ error کا متن درست طور پر assign ہوا تھا مگر کہیں بھی دکھایا نہیں گیا۔ یہ ایک حقیقی outage کے دوران سامنے آیا جب API اکاؤنٹ کا credit ختم ہو گیا۔
| طے شدہ کوڈ، ٹیسٹ رنز |
کامیاب |
pass 4, fail 0 |
| Bug دوبارہ داخل، وہی ٹیسٹ |
پکڑا گیا |
pass 2, fail 2 |
| فائل بحال، ٹیسٹ چلتا ہے |
کامیاب |
sha256 54f8802b444b6194… |
یہ ٹیسٹ بے معنی نہیں: بگ واپس آئے تو یہ فیل ہو جاتا ہے۔
آپریشنل ریکارڈ
پلیٹ فارم کے پیچھے کیا موجود ہے، اور کیا غیر ٹیسٹ شدہ ہے۔ صرف وہی جو کوئی اسکرپٹ یا لاگ دکھا سکے۔
- بیک اپس: رات کو 03:17 UTC، pg_dump --clean --if-exists، gzip؛ ہر رن کے بعد ایک نجی git remote پر push کیا جاتا ہے؛ تازہ ترین
20261003T031701Z؛ 29 ڈمپس محفوظ رکھے جاتے ہیں۔
- بحالی کی مشق 2026-10-03: ڈمپ
20261003T031701Z کو اسی ہوسٹ پر ایک عارضی pgvector/pgvector:pg16 کنٹینر میں 2 s میں بحال کیا گیا: 34 ٹیننٹس، 270 نالج قطاریں، 47 ٹیبلز۔ ڈمپ 03:17 UTC کا ہے؛ 13:26 UTC پر طے شدہ ڈیمو صفائی نے 30 دن سے پرانا ایک متروک ڈیمو ٹیننٹ ہٹا دیا (gateway لاگ)، اس لیے بحالی میں مشق کے وقت لائیو سے ایک ٹیننٹ زیادہ دکھائی دیتا ہے۔
- رول بیک: سائٹ: tools/deploy-site.sh --rollback (پچھلی ریلیز پر دوسرا symlink فلپ)؛ Studio: tools/deploy-studio.sh --rollback (پچھلی امیج، ہیلتھ چیک شدہ)۔
- بحالی کے اہداف: کوئی وعدہ نہیں۔ رات کا ڈمپ ڈیٹا کے نقصان کو ایک دن تک محدود رکھتا ہے؛ بحالی کا کوئی طے شدہ وقت بیان نہیں کیا گیا۔
- غیر ٹیسٹ شدہ: ایک انسٹینس سے زیادہ لوڈ؛ ملٹی ریجن فیل اوور؛ کسی دوسرے ہوسٹ پر بحالی۔
docs/ops-record.json سے، جسے بحالی کی مشق (docs/runbooks/db-backup.md) نے لکھا۔
یہ کیا ثابت نہیں کرتا
یہ میرے اپنے کوڈ پر خود چلائی گئی جانچیں ہیں۔ یہ دکھاتی ہیں کہ مخصوص ٹیسٹ مخصوص بگز پکڑتے ہیں: یہ نہیں کہ نظام دوسرے بگز سے پاک ہے، نہ یہ کہ آڈٹس جامع تھے، اور نہ یہ کہ کسی آزاد فریق نے اس کا جائزہ لیا ہے۔ ہارنیس ریپوزٹری میں موجود ہے؛ دعویٰ اسے چلا کر جانچا جا سکتا ہے۔
PANTHEON · ثابت کریں، لائیو سسٹم پر حملہ کریں · آڈٹ ریکارڈ · واک تھرو · کام · CV
یہاں کسی بھی نقص کے بارے میں پوچھیں، اور یہ کہ اس کا ٹیسٹ اصلاح کو کیسے ثابت کرتا ہے۔
- مجھے ایک حقیقی bug دکھائیں جو انہوں نے ڈھونڈا اور ٹھیک کیا
- آپ کو کیسے معلوم کہ کوئی ٹیسٹ ناکام ہو سکتا ہے؟
- کیا چیز اب بھی کھلی ہے؟