Докази

Будь-хто може заявити, що баг виправлено. Ця сторінка показує виправлення, тест, який його охороняє, і доказ, що тест падає, коли баг повертається.

Згенеровано 2026-10-03 з tools/prove_regressions.py · доведено, що 4 з 4 регресійних тестів не є порожніми.

Як отримано кожен доказ

Запустіть регресійний тест на виправленому коді: він має пройти.
Відредагуйте код, щоб повернути початковий баг.
Запустіть той самий тест ще раз: він має впасти, зі справжньою помилкою перевірки (assertion). Помилка збирання не рахується: вона означає, що тест так і не запустився.
Відновіть файл, перевірте, що його SHA-256 збігається з оригіналом, і запустіть знову: тест має знову пройти.

Асистент казав відвідувачам, що вебхук передає їхню розмову. Він не передає з неї нічого.

коміт e027e6b · захищено apps/gateway/tests/test_webhook_content_claim.py

Корисне навантаження вебхуків навмисно містить лише ФОРМУ ходу: назву події, мітку часу, кількість кроків, кредити, і ніколи не містить його вмісту. Асистент на запитання, чи включають вебхуки розмову, відповів: «Так, кожне корисне навантаження вебхука містить повну історію розмови для цього ходу.» Це прямо протилежне гарантії, на відповідність якій тестується allow-list. До виправлення виміряно 2 вигадки на 6 запусків.

Виправлений код, запуски тестів	PASS	`21 passed in 1.15s`
Баг повернено, той самий тест	ПЕРЕХОПЛЕНО	`8 failed, 13 passed in 1.20s`
Файл відновлено, тест запущено	PASS	`sha256 a8d4cb0b10787eff…`

Тест не порожній: він падає, коли баг повертається.

Ми казали власникам натиснути картку на панелі, якої не існує.

коміт b4a203a · захищено тестом apps/gateway/tests/test_card_names.py

База знань, документація і стартова плитка радили власникам знайти картку 'Send turns to a webhook'. Справжня картка на панелі називається 'Send events to your own system'. Назву вигадали під час написання розділу знань, і вона без перевірки поширилася в три місця. Виміряно: 2 з 2 відповідей щодо налаштування називали елемент керування, якого ніколи не існувало.

Виправлений код, запуски тестів	PASS	`5 passed in 1.12s`
Баг повернено, той самий тест	ПЕРЕХОПЛЕНО	`3 failed, 2 passed in 1.23s`
Файл відновлено, тест запущено	PASS	`sha256 f6348e1a5bbae209…`

Тест не порожній: він падає, коли баг повертається.

Привітання в темному режимі відображалося з контрастом 1.73:1, тобто було фактично невидимим, і перевірка не могла цього виявити.

коміт ca47f41 · захищено apps/studio/test/themeContrast.test.mjs

Виявлено за скриншотом зі справжнього iPhone, а не жодним тестом. Вітальне повідомлення мало жорстко заданий колір #3a3a3c, що дає 1.73:1 на тлі панелі темного режиму: значно нижче мінімуму 4.5:1 і ледь читається. Це бачив кожен новий відвідувач у темному режимі. Виправлення передає колір через змінну теми --pw-mist, тож він відповідає панелі; перевірка тепер обчислює фактичний коефіцієнт контрасту для кожної тематичної пари, а не довіряє тому, що колір задано.

Виправлений код, запуски тестів	PASS	`pass 5, fail 0`
Баг повернено, той самий тест	ПЕРЕХОПЛЕНО	`pass 3, fail 2`
Файл відновлено, тест запущено	PASS	`sha256 54f8802b444b6194…`

Тест не порожній: він падає, коли баг повертається.

Невдала репліка залишала відвідувача вічно чекати на мертвому потоці.

коміт 4bcc691 · захищено apps/studio/test/streamError.test.mjs

Коли виклик моделі завершився помилкою, сервер коректно надіслав фрейм помилки, але віджет записав повідомлення в елемент, який гілка governance-trace вже приховала, і так і не згорнув trace. Відвідувач бачив «Читаю ваше повідомлення», що пульсувало безкінечно на ході, який уже завершився невдачею: жодної помилки, жодного відновлення, жодного способу дізнатися. Текст помилки було присвоєно правильно, але ніде не відмальовано. Виявлено під час реального збою, коли на акаунті API закінчився кредит.

Виправлений код, запуски тестів	PASS	`pass 4, fail 0`
Баг повернено, той самий тест	ПЕРЕХОПЛЕНО	`pass 2, fail 2`
Файл відновлено, тест запущено	PASS	`sha256 54f8802b444b6194…`

Тест не порожній: він падає, коли баг повертається.

Операційний журнал

Що існує за платформою і що не протестовано. Лише те, що може показати скрипт або журнал.

Резервні копії: щоночі о 03:17 UTC, pg_dump --clean --if-exists, gzip; після кожного запуску надсилаються до приватного git-репозиторію; остання 20261003T031701Z; зберігається 29 дампів.
Тренування з відновлення 2026-10-03: дамп 20261003T031701Z відновлено за 2 с у тимчасовий контейнер pgvector/pgvector:pg16 на тому самому хості: 34 орендарі, 270 рядків знань, 47 таблиць. Дамп зроблено о 03:17 UTC; о 13:26 UTC планове очищення демо видалило одного покинутого демо-орендаря, старшого за 30 днів (журнал шлюзу), тому відновлена копія показує на одного орендаря більше, ніж було в робочій системі на момент тренування.
Відкат: сайт: tools/deploy-site.sh --rollback (повторне перемикання symlink на попередній реліз); Studio: tools/deploy-studio.sh --rollback (попередній образ, з перевіркою працездатності).
Цілі відновлення: жодних не обіцяно. Нічний дамп обмежує втрату даних одним днем; час відновлення не заявлено.
Не протестовано: навантаження понад один екземпляр; міжрегіональне перемикання при відмові; відновлення на інший хост.

З docs/ops-record.json, який записує тренування з відновлення (docs/runbooks/db-backup.md).

Чого це не доводить

Це перевірки, які я сам запускаю на власному коді. Вони показують, що конкретні тести ловлять конкретні баги, але не те, що система вільна від інших, не те, що аудити були вичерпними, і не те, що хтось незалежний її перевіряв. Обв'язка є в репозиторії; твердження можна перевірити, запустивши її.

PANTHEON · Доведіть: атакуйте живу систему · Журнал аудиту · Покрокові розбори · Роботи · CV