Що було протестовано

Тест Telegram у реальному часі, весь акаунт · 29 жовтня 2026 року#

Цей самий акаунт продовжував працювати після наведеного нижче тесту. 29 жовтня о 12:10 за UTC його сфера дії була розширена на весь акаунт (канали, групи, приватні чати та боти); панель запросила підтвердження, і підписаний журнал зафіксував це. Станом на 17:59 за UTC журнал містив:

• Перевірка Verify, проведена експертною групою, підтвердила підписи та ланцюжок хеш-кодів усіх 9 968 записів.
• Повідомлення надійшли з 2 груп або каналів та 3 приватних чатів і ботів. Була натиснута одна кнопка повідомлення в розділі «Чати»; запит та відповідь Telegram містяться в журналі.
• Нові чати додавалися, коли колектор повторно сканував обліковий запис після перезапуску. Функція збереження попередніх повідомлень нових чатів була вимкнена (history = 0), тому вона тут не розглядається.

Не охоплюються: реакції, зміни у складі учасників, профілі користувачів, надсилання повідомлень, приєднання за запрошенням, проксі-сервери, сповіщення, бот-свідок та одночасне використання кількох облікових записів. Публічні файли містять лише статистичні дані.

Експорт, захищений паролем, відкривається за допомогою libarchive · 29 жовтня 2026 року#

Архів, створений за допомогою коду шифрування експорту (WinZip AES-256, формат, який читають 7-Zip та WinRAR ), було відкрито за допомогою Windows tar (bsdtar 3.6.2, libarchive). При введенні правильного пароля витягнутий файл збігався з оригінальним SHA-256; при введенні неправильного пароля з’являлося повідомлення «Неправильна парольна фраза». Самі програми 7-Zip та WinRAR не запускалися.

Тестування Telegram у реальному часі · 27–29 жовтня 2026 року#

Один реальний обліковий запис Telegram, увійшовши через вбудований пул пар API, записав дані однієї супергрупи з 27 жовтня 21:36 UTC до 29 жовтня 05:15 UTC. Колектор було запущено 12 разів протягом цього періоду.

• Підписи та ланцюжок хеш-кодів усіх 2 385 записів перевіряються за допомогою відкритого ключа журналу.
• Після перезапуску колектор продовжує роботу зі збереженого стану оновлення (pts), а Telethon наздоганяє пропущене; під час повторної перевірки додаються повідомлення, яких ще бракує.
• При кожному виклику FloodWait колектор очікував протягом заданого часу, а потім продовжував роботу.
• Акаунт залишався увійшов у систему, і та сама сесія відновилася 29 жовтня.

Цей тест не охоплює: одночасне використання кількох облікових записів, ролі адміністратора, проксі-сервери, перебої в роботі, тривалістю понад кілька годин, а також повну процедуру прийняття даних у режимі реального часу. Публічні файли містять лише такі дані: жодних ідентифікаторів облікових записів чи чатів, повідомлень або уповноважень.

Старіші записи нижче описують окремі цикли роботи; у більшості з них використовувалися синтетичні тестові клієнти. Останні результати автоматизованого тестування наведені нижче.

Вбудовані публічні списки MTProxy · 29 жовтня 2026 року#

Це історичний протокол тестування оригінальної збірки з ручним вибором. Інформацію про поточні режими автоматичного вибору пулу та IP-адрес див. у налаштуваннях підключення. Наведені нижче показники та непідтримувані функції стосуються саме цієї тестованої версії.

Додано пакетний публічний знімок та явне оновлення HTTPS з SoliSpirit/mtproto та zakky8/mtproto-proxy-pro. На цьому хості програма для завантаження додатків успішно отримала обидва канали 29 жовтня 2026 року о 12:58 за UTC: 118 унікальних сумісних кінцевих точок після фільтрації, дедуплікації та обмеження до 64 записів на джерело. Це підтверджує отримання списку, а не підключення чи доставку повідомлень через ці кінцеві точки. Під час цієї роботи жоден реальний обліковий запис не був підключений до проксі-сервера зі списку. Посібник для оператора та користувача.

У разі невдалих, порожніх або несумісних відповідей джерела попередні записи та дати зберігаються. Оновлення не змінюють обраний маршрут. Публічні адреси перевіряються, а IP-адреси, що вирішуються, фіксуються під час вибору; маршрути оператора та ручні маршрути залишаються окремими. Тест з’єднання тепер доступний на панелі ще до входу в обліковий запис. Підроблені TLS-сертифікати та автоматичний вибір проксі-сервера залишаються непідтримуваними. Каталог оператора повністю замінює підписки.

• Повний набір тестів: 366 пройшли, 3 пропущено, 287,94 секунди. Існуючі попередження про залежності та пропуски платформ залишаються. Остаточна регресія публічного списку/локалізації: 36 пройшли, включно з відхиленням недійсних портів проксі-серверів для завантаження; це перекривається з повним набором тестів.
• Перевірка сумісності з браузерами пройшла для англійської/російської мов, світлого/темного режиму при розмірі 390/1440 пікселів: вбудовані варіанти вибору, відсутність зовнішніх запитів під час відкриття налаштувань, явне оновлення, збереження маршрутів та кешу під час збоїв, перевірка перед входом, ізоляція робочого простору при затримці відповіді, деталі джерела та макет/контраст. Відсутність помилок JavaScript або зовнішніх запитів браузера.
• Остаточний статичний переклад затверджено для всіх 13 мовних версій; новий текст перекладено російською мовою з явним зазначенням англійських варіантів у інших місцях. Оновлений вбудований посібник пройшов перевірку верстки та контрастності в обох темах.
• Пройдено перевірку Ruff та публікацій (259 публічних файлів, 1 354 локальних посилань); оновлено розбір YAML-файлів Compose та CI. Docker та віддалена CI тут не виконувалися.
• Перероблений модуль пройшов перевірку на ізольовану інсталяцію, завантаження списку пакетів та перевірку підписаного експорту. Усі 69 ресурсів пакета відповідали робочому простору; хеші вихідного коду були перевірені.

Квитанції: test-results/public-proxy-research/download-receipt.json, test-results/public-proxy-research/copy-receipt.json, test-results/public-proxies-full-suite.log, test-results/public-proxies-final-focused.log, test-results/public-proxies-browser/receipt.json та test-results/public-proxies-package.log. Параметри браузера, облікового запису та транспортного протоколу є вигаданими; два наведені вище запити на завантаження каналів є реальними HTTPS-запитами.

Презентація додаткових опцій · 29 жовтня 2026 року#

Колишня сторінка бота Proof тепер називається «Extras»: короткий огляд, за яким слідує окрема сторінка налаштувань для обраної опції. Форма свідка складається з трьох кроків, при цьому управління з’єднанням, мережеві параметри та деталі розгортання приховані. GitHub явно передбачений і не має форми для введення облікових даних. Огляд російською мовою.

• Пройдено 30 цільових тестів на локалізацію, налаштування TgWitness та перевірку публікацій.
• Перевірка налаштувань Chromium пройшла успішно в англійській/російській мовах, у світлому/темному режимі, при розмірі 390/1440 пікселів: фокус клавіатури та повернення, відсутність неявних зв’язків під час вибору додаткових опцій, збереження чернеток, закріплені налаштування/завантаження токенів, очищення токенів при блокуванні та працездатні посилання на локальні інструкції. Перевірки контрасту тексту на тлі з суцільним фоном пройдені.
• Перевірка на підтримку перемикання робочих просторів пройшла успішно, включаючи затримку у відповіді токена, що надходить після перемикання. Швидка навігація дозволяє знайти додаткові матеріали за допомогою термінів «бот», «доказ» та «GitHub»; існуючі перевірки на роздільну здатність 320/390/1440 пікселів та підтримку російської мови/RTL також пройшли успішно.
• Під час тестового запуску не було виявлено помилок JavaScript або зовнішніх запитів до браузера. Це синтетичні перевірки інтерфейсу користувача, а не нові реальні докази публікацій у Telegram або ботах.
• Завершено завантаження мов та охоплення словників для всіх 13 локалізацій із збереженням явних англійських запасних варіантів поза межами російської мови. Розширений посібник Proof також пройшов перевірку макету та контрасту при роздільній здатності 320/768/1440 пікселів в обох темах.
• Перероблений інструмент пройшов перевірку на ізольовану інсталяцію та перевірку підписаного експорту. Усі 67 упакованих ресурсів відповідали робочому простору; вихідний архів містить 253 загальнодоступні файли. Перевірка джерел/посилань пройшла успішно для 1 346 локальних посилань на документацію.

Квитанції: test-results/setup-browser/receipt.json, test-results/quick-navigation/receipt.json, test-results/extras-final.json, test-results/extras-package.log та test-results/extras-artifacts.json. У скріншотах використано синтезовані робочі простори.

Аудит налаштування бота Witness та проксі-сервера · 29 жовтня 2026 року#

Налаштування свідка (тепер «Додатки» → «Бот у вашому каналі») готує незалежно розгорнутого свідка: закріплений ключ колектора, завантаження токена з обмеженим доступом, власний канал, політику публікації, маршрут HTTP/SOCKS5 та власний Bot API. Токен бота залишається на хості «witness». Його новий --check-config перевіряє конфігурацію та файли без встановлення мережевого з’єднання або створення ключа. Шляхи до JSON- файлів визначаються поруч із конфігурацією. Усі варіанти «witness» у Compose тепер передають налаштування HTTP-проксі та Bot API.

Налаштування облікового запису підтримують публічний каталог MTProxy, що керується оператором, налаштований попередній перегляд проксі-посилань Telegram та існуючі поля для ручного введення. У відповідях каталогу не розкриваються секретні дані; при виборі маршрут зберігається у сховищі робочого простору. У разі відсутності або неправильного формування каталогів залишаються доступними маршрути, введені вручну. Адреси проксі-серверів проєкту або хостована служба свідків не створюються та не вмикаються за замовчуванням. Приклад Caddy відкриває доступ лише до кінцевої точки head з обмеженим доступом, коли зовнішній свідок повинен зв’язатися зі збирачем, панель якого залишається приватною.

Перевірка:

• Повний набір тестів: 348 пройшли, 3 пропущено, 195,81 секунди. Пропуски пов’язані з обмеженнями Windows; дві існуючі попередження про застарілість залежностей залишаються.
• Остаточний регресійний тест для версій witness/configuration/release: 11 пройшли, 1 пропущено. Це перекриває повний набір тестів. Тести включають визначення шляху, офлайн-перевірку перед запуском, підписання/публікацію через реальну фіксовану конфігурацію HTTP Bot API з петлевим з’єднанням, зареєстровану невдачу доставки, перевірку токена каналу та виключення секретного ключа проксі-сервера.
• Перевірка налаштувань Chromium пройшла англійською/російською мовами при розмірі 390/1440 пікселів: закріплені налаштування та завантаження токенів, очищення токенів при блокуванні, вибір каталогу, попередній перегляд користувацьких посилань з подальшим явним збереженням, правильним макетом/контрастом та відсутністю помилок JavaScript або зовнішніх запитів браузера. Виправлено вузький заголовок російського облікового запису та переповнення вкладки входу.
• Пройшли перевірки Ruff, джерел/посилань та аналіз YAML-файлів Compose/workflow.
• Перероблений модуль пройшов перевірки ізольованої інсталяції, панелі/статичних ресурсів та авторизації через API, а також незалежну верифікацію прямих та потокових синтетичних експортів із 32 подіями.

Квитанції: test-results/setup-full-suite.log, setup-final-focused.log, setup-browser/receipt.json, setup-browser-final.log та setup-package.log. Ці перевірки використовують синтетичні акаунти/проксі та локальний фікстур Bot API. Вони не претендують на реальну публікацію бота, працюючий публічний сервер MTProxy, віддалений запуск CI або розгортання Docker. Збережена вище реальна історія спостережень у Telegram залишається окремим доказом. Інструкції з налаштування.

Огляд презентації та документації · 29 жовтня 2026 року#

Сторінка продукту, екран доступу, файли README англійською та російською мовами, а також зображення презентації тепер мають єдиний візуальний стиль. У публічних скріншотах використовуються вигадані демонстраційні дані. Під час перегляду також було виправлено застарілі описи функцій перевірки в режимі реального часу та відновлення, наведені вище.

• Цільова локалізація, тестування сайту та публікацій: 33 пройдені, 1 пропущений. Пропущений тест вимагає створення символічного посилання, що недоступне на цьому хості.
• Пройшла загальна перевірка панелі Chromium, включаючи всі мовні каталоги, макет RTL, світлі/темні теми, достатній контраст тексту та перемикання робочих просторів. Перевірка створення профілю тепер очікує на фактичну HTTP-відповідь перед перевіркою вибраного робочого простору.
• Екрани доступу англійською та російською мовами пройшли перевірку макету та контрастності в обох темах при роздільній здатності 320, 390, 768, 850 та 1440 пікселів; кнопка «Відправити» залишається у початковій області перегляду.
• Сайт пройшов перевірку на сумісність з роздільною здатністю 320, 390, 768, 1024 та 1440 пікселів, включаючи елементів керування історією повідомлень, збільшення скріншотів/клавіші Escape/повернення фокусу, перехід між вкладками за допомогою клавіатури, відмову від буфера обміну, підшляхи проєкту, зменшену анімацію та резервний варіант без JavaScript. Не було зафіксовано жодних невдалих запитів на ресурси, зовнішніх запитів або помилок JavaScript.
• Перероблений модуль пройшов перевірку ізольованої інсталяції: завантажуються ресурси панелі та локалі, доступ до API вимагає автентифікації, а прямий та потоковий експорт незалежно перевіряють усі 32 синтетичні події. Перевірки Ruff та відкритих джерел/посилань пройдені.

Локальні квитанції: test-results/design-tests.log, design-panel-final.log, design-review-final.log, design-site.log та design-package/install-receipt.json. Повний набір серверних програм не було перезапущено для цієї презентації/зміни документації; попередні результати залишаються в аудиті, проведеному перед публікацією.

Версія 0.6.1#

У версії 0.6.1 змінено вигляд панелі, запускачі, упаковку та документацію; код збору, зберігання, підписання та експорту залишився без змін. На Windows 11 / Python 3.12.10 із закріпленим середовищем виконання:

• Повний набір пройшов 137 тестів із 2 пропусками та існуючим попередженням щодо Starlette. Нові тести охоплюють обробку комбінації клавіш Ctrl+C у програмі запуску (сервер отримує 30 секунд для впорядкованого завершення роботи) та помилки на етапах налаштування, що вимагають втручання.
• Chromium (безграфічний інтерфейс 156) пройшов усі 45 загальних сценаріїв та 35 сценаріїм імпорту облікових записів/QR-кодів/аутентифікаційних ключів, включаючи перевірку контрасту суцільного тексту, відсутність горизонтального переповнення при розмірах 320–1440 пікселів та видимість полів першого входу при розмірах 320/390 пікселів. Помилок JavaScript на сторінці та зовнішніх запитів виявлено не було.
• python start.py --setup-only перевстановив пакет у версії 0.6.1, а python start.py --check повідомив про готовність. Справжній сервер python -m tgwitness --demo надав панель, таблицю стилів, скрипт, логотип, посібник та /api/status версії 0.6.1; видалений workspace.css повернув код 404.
• Start.cmd виявив інсталяцію Python поза PATH. Оскільки Python був недоступний, було показано пропозицію щодо інсталяції; відхиливши друковані інструкції, система вийшла з режиму 1. На етапі завантаження з python.org було отримано інсталятор версії 3.12.10, який пройшов перевірку Authenticode від Python Software Foundation; сам інсталятор на цьому хості не запускався.
• start.sh, без використання Python, вивів підказку щодо встановлення та завершив роботу 1. scripts\Docker.cmd та scripts/docker-start.sh були протестовані на підроблених виконуваних файлах docker: правильна послідовність викликів, адреса панелі та виведення токена, а також відсутність повідомлення про успіх після збою.
• python tools/build_portable.py створив пакет для Windows розміром 18,8 Мбайт після перевірки закріпленої контрольної суми вбудованого середовища виконання. Після розпакування у шлях із пробілами та запуску лише з каталогами C:\Windows у PATH, вбудований Python пройшов перевірку TgWitness-Check.cmd, забезпечив роботу демоверсії (32 події) та робочого простору в режимі реального часу, а Chromium відтворив журнал та панель деталей без помилок JavaScript. Дані були записані у папку data пакета.
• python tools/build_preview.py створив архів вихідних файлів із 110 файлами. Пробний запуск git add перелічив ті самі 110 файлів без файлів сеансів, ключів, баз даних, токенів, журналів або експорту, без локальних абсолютних шляхів та без рядків, що нагадують секретні дані.

У цьому конкретному циклі пакування від 27 жовтня не було виконано: саму автоматичну інсталяцію Python, перевірки Docker build/Compose, запуски на Linux/macOS або нове тестування на реальному акаунті. Реальні докази з Telegram зафіксовано вище та в попередніх перевірках акаунтів, наведених нижче. Самі лише визначення CI не підтверджують працездатність платформи.

Версія 0.6.0#

Останній повний набір тестів із закріпленим часом виконання на Windows 11 / Python 3.12.10 пройшов 135 тестів, з 1 пропущеним, за 26,53 секунди та існуючим попередженням Starlette. Пропуск вимагає прав доступу POSIX. Після додавання рендерера QR-кодів до перевірок готовності та вимірювань процесів 8 відповідних перевірок готовності/робочого простору також пройшли успішно.

Нові можливості охоплюють схеми Telethon 7/8, схеми Pyrogram 2/3, повні JSON- ключі та JSON, що містить лише метадані, файли облікових записів із збігами/суперечностями, паролі TData, фальсифікацію контрольних сум та небезпечні шляхи, офлайн/автентифіковане перетворення в пам’яті, онлайн-перевірку ідентифікаторів облікових записів, успішність QR-кодів/2FA/термін дії, скасування застарілих даних та ізоляцію облікових записів. Фікстури TData використовують окрему реалізацію AES-IGE для шифрування.

Chromium пройшов 45 загальних сценаріїв та 35 сценаріїв імпорту облікового запису/QR-коду/аутентифікаційного ключа, при цьому не було виявлено жодних помилок JavaScript на сторінці чи зовнішніх запитів. Нові перевірки браузера охоплюють усі чотири формати введення даних разом, захищені дані TData, метадані API, відображення QR-кодів, термін дії/повторні спроби, двофакторну автентифікацію (2FA), відхилення неправильного облікового запису, блокування/скасування робочого простору, адаптивний макет та затримки у відповідях на перетворення після вибору нового файлу.

Обидва набори браузерів знову пройшли перевірку після змін у введенні даних облікового запису. Налаштування в режимі реального часу відкриває форму облікового запису; демо-режим відкриває зразок журналу. Демо-сторінка «Обліковий запис» показує інструкції щодо запуску в режимі реального часу та приховує поля введення облікових даних. Цільові перевірки при розмірах 320, 390 та 1440 пікселів підтвердили, що поле введення числа та основна кнопка вміщуються на екрані без прокрутки, поля API спочатку згорнуті, а контрастність тексту залишається читабельною. Елементи керування записом та перевіркою залишаються прихованими після відкриття їхніх нових розгортальних розділів.

Прямий потік Auth Key було протестовано з використанням синтетичних облікових даних через реальні кінцеві точки імпорту та авторизації. Перевірки охоплюють неповні ключі, відсутність DC, неточні ідентифікатори користувачів, невідповідність ідентичності облікового запису, збережені облікові дані API, видимий прогрес запиту, очищення секретних даних та запізнілі відповіді після редагування або зміни методу. Усі чотири методи входу були перевірені при розмірах 320, 390 та 1440 пікселів. Вікно вибору файлів відображається до підказки щодо формату, а кнопка «Підключитися» вміщується у початкову область перегляду розміром 844 пікселі зі згорнутими налаштуваннями API. Під час цього тестування прийнятності інтерфейсу користувача не здійснювалося жодних спроб авторизації за допомогою реального ключа авторизації.

Оновлення панелі було ще раз перевірено за допомогою обох наборів браузерів: не було виявлено жодних помилок JavaScript на сторінці або зовнішніх запитів. Набір облікових записів тепер охоплює вставку однієї пари API-ідентифікатора та хешу, відхилення неправильно сформованих або множинних пар без заміни полів, вказівки щодо використання лише метаданих, а також ігнорування застарілих відповідей на імпорт після зміни методу входу або ручного редагування облікових даних. Шість додаткових цільових перевірок було успішно пройдено щодо посібника з налаштування, явного запуску/паузи, відновлення після порожнього пошуку, а також остаточного макета підключення/локального посібника та надійного контрасту тексту при роздільній здатності 320, 390 та 1440 пікселів. Оновлення прямого входу додає операцію з одним номером телефону/запитом коду та повторно використовує збережену пару API поточного робочого простору для входу за номером телефону, QR-кодом та сесією. Повний набір тестів на Python, зазначений вище, включає нові тести на збереження даних, відхилення часткових облікових даних та ізоляцію робочого простору. Перевірки в браузері охоплюють пряме введення номера телефону, повторне використання збережених облікових даних, маршрутизацію лише за метаданими, авторизацію файлів однією кнопкою та відхилення дублікатів облікових записів. Спрощені форми для введення токена з панелі та номера телефону також були перевірені без початкового прокручування при розмірах екрану 320, 390 та 1440 пікселів. Перевірка сумісності підтвердила, що форма прямого введення номера телефону може використовувати попередні кінцеві точки конфігурації/коду, поки все ще виконується старий процес.

Один наданий користувачем обліковий запис було перевірено окремо, поза межами публічних тестових наборів. Його вхідні дані Telethon, Pyrogram та TData вказували на однакову авторизацію; супровідний файл JSON містив облікові дані API. Усі чотири файли було завантажено через панель версії 0.6.0, і Telegram підтвердив очікуваний числовий ідентифікатор облікового запису. Вихідні файли залишилися без змін. Жодні джерела не були обрані, а режим спостереження залишався вимкненим. Це відповідає одному прикладу імпорту/входу, а не збору даних у реальному часі, відновленню або пропускній здатності.

Telegram також видав реальний QR-токен, який було скасовано без сканування. Повний процес підтвердження за QR-кодом та 2FA було відпрацьовано за допомогою синтетичних клієнтів; мобільне підтвердження за допомогою справжнього додатка Telegram залишається окремим етапом авторизації. У публічних файлах не містяться жодні реальні ідентифікатори облікових записів, секретні дані чи знімки екрана.

Оновлення запускача завершено; вихідний код, встановлені метадані та маркер готовності повідомляють про версію 0.6.0, з QR-кодом 8.2 та успішним тестом pip check. Встановлений колесо обслуговувало панель та посібник, відхиляло неавтентифіковані запити до API та самостійно перевіряло прямі та потокові синтетичні експорти з 32 подіями. Оновлений офлайн-посібник було перевірено при роздільній здатності 320, 390 та 1440 пікселів. Публічні скріншоти залишаються синтетичними.

Випуск вихідного коду містить 107 файлів із списку дозволених. Посилання на локальну документацію працюють. Виконання в Docker/Caddy, віддалена публікація CI/пакетів, середовище виконання ARM64, безперервний збір даних та повна матриця прийнятності Telegram у режимі реального часу тут не розглядаються.

Версія 0.5.1#

У Windows 11 / Python 3.12.10 повний набір тестів середовища проекту пройшов успішно: 94 пройшли, 2 пропущено, за 31,21 секунди, з існуючим попередженням Starlette. Пропущені елементи вимагають прав доступу POSIX та створення символічних посилань, що недоступні на цьому хості. Фікстура завантаження HTTP вивела діагностику потоку запитів; усі перевірки пройшли успішно. Цей запуск не виключає наявності проблем із транспортом хосту.

Нові тести регресійного покриття охоплюють відхилені StringSession, зміни в коді та облікових записах 2FA, скасування пошуку ідентичності, очікуване скасування входу та оновлення через зареєстровані обробники на активних, відхилених, замінених та тестових клієнтах. Лише активний колектор передає події; збережені облікові дані та підписана історія залишаються незмінними. Інші нові перевірки охоплюють пошук за Unicode після повторного відкриття бази даних, включення меж політики моніторингу в Coverage та виключення пакетів із відкритих джерел.

Фактичний проєкт pythonw.exe запустив ізольовану синтетичну панель, повернув HTTP 200 та зберіг діагностику запуску в logs/server.log. Журнал не містив згенерованого токена панелі або записів про доступ HTTP. Тест завершив лише свій власний синтетичний процес. Жодне завдання Планувальника завдань не було зареєстровано; вхід/вихід із системи, перехід у режим сну та відновлення роботи служби залишаються окремими критеріями.

Тестування на сумісність із Chromium пройшло 45 сценаріїв, при цьому не було виявлено помилок JavaScript на сторінці та зовнішніх запитів. Нові перевірки охоплюють дати та час на часовій шкалі з роздільною здатністю 601/768/850 пікселів, чернетки вкладень під час оновлення статусу, нові редагування, зроблені під час збереження, очищення результатів верифікації при перемиканні між обліковими записами, запізнілі відповіді на верифікацію після переходу на іншу сторінку та повернення, а також чіткі межі верифікації при надходженні нових подій. Також було виправлено інтервал між піктограмою пошуку та текстом, після чого набір браузерів було запущено повторно.

Під час запуску в браузері використовувалося закріплене середовище виконання в .venv та існуючий системний Playwright 1.62.0/Chromium, доданий після середовища проекту у шляху імпорту. Опціональна інсталяція залежностей для розробки була зупинена під час повільного завантаження Playwright; жодну нову версію браузерного інструменту не було визнано придатною. Звичайний python start.py --setup-only завершив оновлення додатка. Джерело, встановлені метадані та маркер запускача повідомляють про версію 0.5.1; pip check пройшов успішно. Перевірки готовності пройшли успішно на новому, не використаному шляху, з збереженням очікуваного попередження щодо локального ключа сховища.

Пакет 0.5.1 було встановлено окремо та протестовано на базову працездатність: усі ресурси панелей/посібників були надані, неавтентифікований доступ до API було відхилено, а як прямі, так і потокові ZIP-файли з доказами, що містять 32 події, пройшли незалежну перевірку. Файли програми в встановленому пакеті були порівняні з вихідним кодом. Публічний архів вихідного коду використовує явний список дозволених типів файлів і відхиляє пов’язані файли вихідного коду; матеріали для виконання, розміщені всередині каталогів з вихідним кодом, виключаються регресійними тестами.

Під час запуску виправлення коду вибірка з відкритих джерел та набір кандидатів у Git містили 86 файлів, без урахування каталогів даних виконання. Сканування на наявність впізнаваних шаблонів приватних ключів, токенів GitHub, токенів ботів Telegram та StringSession не виявило збігів. Це обмежена перевірка шаблонів, а не всебічний аудит секретних даних. Перевірки за правилами ігнорування охоплюють дванадцять поширених артефактів облікових записів/даних/експорту. Файли YAML для робочих процесів, проблем та Compose, а також скрипт завдань для Windows були успішно проаналізовані. Посилання на локальну документацію працюють.

Розглянуто всі сім висновків, зроблених під час перевірки 27 жовтня. Виконання робочого процесу на GitHub, середовище виконання на Linux/macOS/Docker, робота з реальним Telegram, взаємодія з зовнішніми проксі-серверами/TSA та кваліфікація під тривалим навантаженням залишаються поза межами цього локального запуску. Публікація репозиторію, реєстрація сервісу або збір даних з реальних акаунтів не здійснювалися.

Оновлення англійської документації#

Файл README, довідка щодо облікових записів/сесій, робочий процес збору даних та комплексний посібник тепер описують підтримувані вхідні дані, поведінку робочого простору, політики подій та формати експорту англійською мовою. Три загальнодоступні знімки екрана було оновлено з використанням синтетичних даних. На той момент вибірка з відкритих джерел містила 88 файлів, включаючи два нові посібники. Усі 131 локальних посилань у 23 документах Markdown працюють.

Після внесення змін до інтерфейсу та посібника тестування на сумісність із Chromium знову пройшло всі 45 сценаріїв, при цьому не було виявлено жодних помилок JavaScript на сторінках або зовнішніх запитів. Повний набір тестів на Python не виконувався повторно для цього оновлення документації та презентації; наведений вище результат із 94 успішними проходженнями належить до попереднього циклу виправлення коду.

Перероблене колесо було встановлено на нову ізольовану ціль. Його панель та навігаційні елементи працювали успішно, неавтентифікований доступ до API було відхилено, а як прямий, так і потоковий експорт пройшли незалежну перевірку на 32 синтетичних подіях.

Оновлення щодо встановлення та розгортання#

Спеціалізовані перевірки інсталятора, пакетування та готовності пройшли 14 тестів, при цьому один тест було пропущено через неможливість створення символічного посилання. Перевірки нативного обгорткового модуля охоплюють шляхи з пробілами, переадресацію аргументів, режими налаштування/демонстрації та поширення ненульового коду виходу. Перевірки Git Bash тестують допоміжну оболонку Docker із симульованим демоном, включаючи відсутність Docker, відсутність Compose, невдале очікування стану працездатності та успішний запуск через альтернативний порт. Ці симульовані перевірки не встановлюють сумісність середовища виконання Docker.

Повна копія з відкритого джерела була встановлена в новий каталог Windows, шлях до якого містить пробіли. scripts\Setup.cmd створив нове середовище та встановив закріплене середовище виконання; Start.cmd --check --json повідомив про готовність, не створивши свій цільовий каталог даних. pip check пройшов перевірку. Перекомпільована версія також пройшла перевірку встановленого пакета, включаючи прямий та потоковий експорт 32 подій.

Проаналізовано синтаксис Shell та п’ять файлів YAML для робочих процесів/Compose. Конфігурації Compose для вихідного коду та зображень збігаються щодо налаштувань зберігання та виконання. На цьому етапі вирішено всі 139 локальних посилань у 23 документах Markdown. Вибірка з відкритого джерела містить 99 файлів.

Визначення CI тепер передбачають нову нативну настройку для Windows/Linux/macOS, перевірку працездатності Compose, контроль доступу та збереження даних під час відновлення контейнерів, а також конфігурацію Caddy. Робочий процес релізу блокує публікацію до проходження цих перевірок та додає емульовану перевірку ARM64 на працездатність. Docker недоступний на цьому хості: фактичне виконання Compose/Caddy, видача сертифікатів, виконання на ARM64 та віддалений робочий процес/публікація пакетів залишаються локально без обмежень. Код додатка/інтерфейсу користувача не зазнав змін у результаті цього оновлення; попередні повні результати тестування на Python та у браузері не повторювалися.

Версія 0.5.0#

Повний набір тестів з фіксованим часом виконання пройшов успішно: 81 тест пройшов, 1 пропущено, за 22,00 секунди, з існуючим попередженням Starlette. Перевірка прав доступу POSIX пропускається в Windows. Нові тести обробників надсилають повідомлення, редагування, видалення з обмеженням/без обмеження, реакції, оновлення учасників та повідомлення служби членства через різні політики. Вимкнені категорії не генерують відповідних спостережень у реальному часі; діагностика покриття та явні знімки залишаються доступними. Тести перевіряють збереження політики, розділення робочих просторів, підписані записи аудиту «до» та «після», поведінку при незмінній політиці, сувору валідацію та включення до наступного підтвердження процесу.

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

Прийняття Chromium пройшло 39 сценаріїв, включаючи вхід у локальну демо-версію без введення токена, попередні налаштування моніторингу, перехід від вибору джерела до політики, незалежність для кожного облікового запису, а також перевірки макету для настільних ПК (320/390 пікселів) та контрастності тексту. Помилок JavaScript на сторінці не виявлено. Запити хосту, в які AdGuard вставив свій код, залишаються у квитанції. HTTP-фіксатор завантаження зафіксував скидання з’єднання після того, як клієнт закрив своє з’єднання; перевірки все одно пройшли успішно. Це не результат роботи сервісу в режимі реального часу.

Стандартний лаунчер оновив ізольоване середовище до версії 0.5.0; вихідний код та встановлена версія збігаються, а перевірка за допомогою pip пройшла успішно. Існуюче шифрування сховища секретних даних, відмова у разі неправильного або відсутнього ключа, а також перевірки на підробку підписів та медіафайлів пройшли успішно в повному наборі тестів. Не заявляється про жодне нове шифрування вмісту повідомлень або вкладень у додатку.

Локальна демоверсія перезапускається, щоб зробити доступним оновлений інтерфейс користувача. Існуючі синтетичні записи зберігаються; зупинка старого фонового процесу демоверсії створює офлайн- межу при наступному запуску. Для цих перевірок не використовується жодна реальна сесія Telegram.

Панель, що працювала за адресою localhost:8787, відображала версію 0.5.0, автоматичний доступ до демо-версії, п’ять елементів керування моніторингом та 33 збережені синтетичні події журналу. Окремий встановлений пакет wheel версії 0.5.0 обслуговував усі ресурси панелі та посібника, відхиляв неавтентифікований доступ до API та створював перевірений ZIP-файл із 32 подіями як безпосередньо, так і через допоміжний модуль потокового завантаження. Версії пакетів під час виконання залишаються зафіксованими, як зафіксовано для версії 0.4.

Версія 0.4.0#

Повний набір тестів у режимі прикріпленого виконання пройшов успішно: 78 пройшли, 1 пропущено, за 19,77 секунди. Пропущена перевірка вимагає прав доступу POSIX; попередження про застарілість Starlette TestClient у вихідному коді залишається. Нові тести охоплюють потокове завантаження/маршрутизацію робочого простору, заголовки авторизації, відмову в перезаписі, перенаправлення, урізані відповіді, оголошені/фактичні обмеження розміру, обмежене читання, очищення, файлові системи без жорстких посилань, помилки готовності та режими запуску, які не повинні встановлювати пакети. Тести експорту підтверджують наявність тимчасових файлів у робочій області та вибіркове очищення «сирітських» файлів.

Тестування на сумісність із Chromium пройшло успішно у всіх 36 перелічених сценаріях без помилок JavaScript на сторінці. Програма відтворює імітований вхід за допомогою телефону/коду/двофакторної аутентифікації, перетворені сесії, дві робочі області та окремі маршрути/стани, спостереження, підписи, контрольні точки та запити на часові мітки, а також:

• Макет для настільних комп’ютерів та розміри 320/390 пікселів, відсутність горизонтального виходу за межі екрану, видима навігація, а також поле для першого входу в межах початкового вікна перегляду розміром 844 пікселі.
• Належний контраст тексту на тлі відповідно до порогових значень WCAG AA. Елементи керування, прозорість та фони із зображеннями/градієнтами не враховуються; це не є повним аудитом на відповідність WCAG.
• Реальна відповідь на запит на експорт, сформована за допомогою імітованого вікна вибору файлів/запису в файлову систему ОС, з подальшою незалежною перевіркою ZIP-архіву; скасування запиту не призводить до відправлення запиту на експорт.
• Помилка запису призводить до переривання передачі даних; резервний варіант розміром 128 МіБ відхиляє надмірно великий оголошений відповідь без виділення відповідного корисного навантаження.
• Англійський локальний посібник для настільних комп’ютерів та обох варіантів вузької ширини.

Діалогове вікно збереження в ОС та фактичні записи в браузері обсягом у кілька гігабайтів не були автоматизовані або перевірені. Тести завантаження на Python використовують обмежені блоки даних та фіксовані цикли. Повне прийняття розгортання з реальним Telegram залишається окремим питанням.

Стандартний інсталятор оновив .venv до версії 0.4.0. Вихідний код та метадані інсталяції збігаються; pip check пройшов перевірку. python start.py --check --json повідомив про готовність на новому синтетичному шляху без створення каталогу даних. Попередження щодо зберігання локальних ключів залишається актуальним: журнали/медіафайли не шифруються додатком.

Пакет версії 0.4.0 було скомпільовано та встановлено в окремий каталог. Усі 23 файли програми повністю збігаються з вихідним кодом байт за байтом. Встановлений пакет відображав панель та англійські інструкції/ресурси, відхиляв неавтентифікований доступ до API та експортував синтетичний ZIP-файл із 32 подіями, який пройшов перевірку. Команда потокового завантаження також отримала незалежно перевірений ZIP-файл із запущеної встановленої програми.

Публічна документація та локальний посібник написані англійською мовою; посилання на локальну документацію працюють. PowerShell проаналізував шаблон завдання Windows, а Python — файл plist для macOS. Це перевірки синтаксису, а не виконання служби. Жодне завдання/служба не було зареєстровано. Конфігурація CI тепер включає перевірки готовності, але віддалена CI тут не запускалася.

Під час повторного запуску браузера у версії 0.4 знову було виявлено вставку AdGuard та помилку OSError 10022 у Windows під час очищення сокетів asyncio. Перевірки браузера пройшли успішно; ці спостереження щодо середовища зберігаються, а не розглядаються як стабільна поведінка додатка. Початкові спроби запуску в пісочниці OpenSSL/браузера/pip завершилися невдачею; успішні кваліфікаційні запуски використовували затверджене виконання поза пісочницею.

У версії 0.3.1 зосереджено увагу на виправленнях, що забезпечують готовність до використання#

Перевірки запуску, зберігання доказів та API пройшли успішно: 31 пройшла, 1 пропущена, одне попередження Starlette з боку розробника. Пропущена перевірка стосується прав доступу до каталогів за стандартом POSIX і не може встановити ці права на цьому хості під Windows. Тест на стару версію Python імітує межу між версіями та імпортом; інтерпретатор Python 3.10 не був встановлений або не пройшов перевірку. Наведено нижче результати набору тестів 0.3, який раніше пройшов успішно; повний набір тестів та сценарії для браузерів не перезапускалися для цих цілеспрямованих змін.

Стандартний запускач оновив локальне середовище до версії 0.3.1; вихідний код та встановлені метадані збігаються, а перевірка pip пройшла успішно. Окремо встановлений wheel версії 0.3.1 обслуговував панель/ресурси, відхиляв неавтентифікований доступ до API та створив перевірений синтетичний експорт із 32 подіями. YAML-файл робочого процесу було проаналізовано, але нова перевірка середовища виконання контейнера не була виконана: не було доступного придатного локального середовища виконання Docker/Podman/Linux.

Дивіться висновки щодо готовності, щоб ознайомитися з рештою недоліків у зручності користування, роботі в режимі реального часу та платформі. Цей виправлення не підтримує додаткові операційні системи.

Версія 0.3.0#

Повний набір тестів у закріпленому середовищі виконання пройшов успішно: 61 тест, з одним попередженням про застарілість Starlette TestClient у вихідному коді. Метадані середовища виконання вказують на TgWitness 0.3.0 та python-socks 2.8.2; перевірка pip пройшла успішно. Тестування на сумісність з браузерами пройшло без помилок JavaScript на сторінках.

Wheel-пакет версії 0.3.0 було скомпільовано та встановлено в окремий каталог пакетів. Він обслуговував панель та ресурси, відхиляв неавтентифіковані запити до API та експортував синтетичний журнал із 32 подіями, який пройшов незалежну перевірку. Посилання на локальну документацію працюють. Після корекції нормалізації «bare-key» у MTProxy всі дев’ять тестів підключення/безпеки було успішно виконано повторно.

Нові матеріали включають:

• Ім’я користувача/пароль SOCKS5 та HTTP CONNECT через реальні тестові сервери з петлевим підключенням; непрацюючий налаштований проксі-сервер видає помилку, а не перенаправляє запит до кінцевого пункту призначення.
• Перевірка проксі-серверів, вибір транспортного протоколу MTProxy, відхилення підроблених секретних ключів TLS, збереження даних, ізоляція робочого простору, відхилення змін під час спостереження та виключення секретних даних зі статусу API та підписаних подій.
• Конвертація синтетичних схем Telethon SQLite 7 та 8 у режим «тільки для читання»; незмінний хеш вихідного коду; відхилення інших форматів, SQL-представлень та невирішеного файлу WAL.
• Зовнішній головний ключ сховища: різні похідні ключі робочих просторів, успішне повторне відкриття, відхилення у разі неправильного або відсутнього ключа, а також відсутність неявної міграції існуючих локальних сховищ.
• Налаштування проксі-сервера в браузері, очищення облікових даних, розкриття інформації щодо захисту сховища, сторінка мобільного підключення, авторизація файлів перетворених сеансів, окремі маршрути, а також усі раніше розглянуті сценарії збору та експорту даних за допомогою підробленого клієнта Telegram.

Під час розробки тест із зворотним зв’язком безкінечно чекав на вимкнення вузла-однорангового; під час іншого виконання було зафіксовано скидання з’єднання в Windows після встановлення з’єднання. Тепер тестовий модуль обмежує весь обмін даними та трактує EOF/скидання після завершення встановлення з’єднання як закриття з’єднання. Перевірки рукостискання/аутентифікації залишаються обов’язковими. Це не стосується справжніх провайдерів проксі-серверів і не означає наявності постійного дефекту транспортного протоколу Telegram.

Описане нижче спостереження за запитом хоста AdGuard залишається актуальним. Не використовувалося жодного реального облікового запису Telegram, зовнішнього SOCKS/HTTP-проксі або активного сервера MTProxy. MTProxy є експериментальним, і перевірено лише вибрані параметри та перевірку секретних даних, а не взаємодію в реальному часі. Нові команди перетворення зовнішніх ключів та сеансів були протестовані виключно з використанням синтетичних секретних даних. Linux/macOS/Docker у цьому контексті залишаються неперевіреними.

Наведене нижче вимірювання пропускної здатності версії 0.2 не було повторене і не повинно подаватися як новий тест продуктивності для версії 0.3 з використанням декількох облікових записів та проксі-серверів.

Базова версія 0.2.0#

Перевірено на Windows із Python 3.12.10. Реальний обліковий запис Telegram не підключався.

У тестах вихідного коду використовувалися FastAPI 0.159.1, Uvicorn 0.54.0, Telethon 1.45.0, cryptography 50.0.2, pytest 9.1.1 та Playwright 1.62.0. У зафіксованому середовищі виконання використовуються FastAPI 0.162.0, Starlette 1.10.0, Uvicorn 0.54.0, Telethon 1.45.0 та cryptography 50.0.2. Файл deploy/constraints.txt фіксує закріплені версії середовища виконання; файли deploy/requirements.lock та deploy/build.lock містять SHA-256 кожного файлу пакета, і Docker та сервери з високим рівнем безпеки виконують інсталяцію виключно з них (pip --require-hashes). Це не є доказом сумісності на кожній налаштованій платформі CI. Віддалена CI не запускалася.

Оцінка синтетичних місцевих можливостей#

Команда: python tools/check_capacity.py --events 10000 --chats 100

Цей показник вимірює локальний послідовний шлях запису/експорту на цьому хості під управлінням Windows. Він не вимірює доставку через MTProto, одночасну роботу декількох облікових записів, обмеження пропускної здатності Telegram, мультимедіа, тривалі робочі навантаження або гарантовану кількість реальних чатів. Вимірювання було проведено до впровадження остаточної версії інструменту для офлайн-маркування часом, який не змінює виміряний шлях повідомлень.

Спостереження за навколишнім середовищем#

Обмеження пісочниці Windows заблокували тимчасові каталоги pytest/pip за замовчуванням та підпроцес Playwright. Pytest використовував новий тимчасовий каталог усередині проєкту; процеси інсталяції та роботи браузера вимагали дозволеного виконання поза межами пісочниці.

Програма AdGuard, встановлена на комп’ютері, вставляла запити до local.adguard.org у браузер. У журналу браузера збереглися ці запити. Цей запуск не є доказом повної відсутності вихідних запитів у немодифікованому середовищі браузера; сам код програми не містить запитів до зовнішніх ресурсів, CDN чи аналітичних сервісів. Налаштування AdGuard не змінювалися.

Під час останнього запуску браузера також було зафіксовано помилку OSError 10022, пов’язану з очищенням сокетів asyncio в Windows. Усі перевірки браузера пройшли успішно, і помилок JavaScript на сторінках не виникло. Причина помилки не встановлена, і цей запуск не свідчить про відсутність проблем із транспортом хосту.

Перший HTTP-тест встановленого пакета, що використовував запити на закриття з’єднання з urllib, зіткнувся з перезавантаженням з’єднання як усередині, так і поза пісочницею, причому з обома наборами залежностей. Останній тест використовував стандартні стійкі з’єднання HTTP/1.1 через http.client і пройшов успішно. Запити браузера також пройшли успішно. Точна причина перезапусків не була встановлена; їх не визнали фіксованим дефектом додатка.

Решта кваліфікаційних вимог#

Збережений журнал у режимі реального часу фіксує факти збору, редагування, повідомлення про видалення, вкладення, повторні перевірки та обробку обмежень швидкості. Він не фіксує вичерпну інформацію про доставку або контрольовану матрицю видимості ролей, суб’єктів, що реагують, тривалого FloodWait, блокування облікових записів та відновлення після перебоїв у роботі мережі/процесів. Видача QR-токенів залишається окремим процесом від завершеного підтвердження за допомогою мобільного QR-коду.

Створення/запуск у Docker, інсталяція на Linux/macOS, стійке високе навантаження, незалежна перевірка безпеки, реальна незалежна реакція TSA, перевірка анулювання/архівування сертифікатів та криміналістична сертифікація залишаються поза межами зафіксованої кваліфікації. Збереження стану MTProto та функція наздоганяння реалізовані; атомарне стійке відтворення залишається нереалізованим. Збір журналів адміністратора, додаткові списки реакторів та пріоритетне коротке опитування залишаються окремими функціями. Дивіться актуальну версію матриці контрольованої кваліфікації.

Детальні локальні квитанції та скріншоти знаходяться в папці test-results/ (ігнорується Git). Публічний скріншот у папці docs/assets/ містить лише вигадані демонстраційні дані.

Підготовка публічного веб-сайту та публікації · 27 жовтня 2026 року#

Окрема презентація website/ та збірка Pages були додані після проведення вищезазначених перевірок. Конфігурація активних облікових записів та логіка збору даних не змінювалися.

• Існуючий набір додатків пройшов перевірку: 138 тестів пройшли, 1 тест, що працює лише з POSIX, було пропущено, та одне попередження про застарілість Starlette/httpx у вихідному коді. 11 доданих тестів на збірку сайту пройшли незалежно, включаючи відхилення несподіваного виводу та відхилення пов’язаного вводу.
• Обидва скрипти для браузера пройшли тестування з використанням project-venv Playwright та Chromium headless shell 156. Не було зафіксовано жодних помилок JavaScript на сторінках або зовнішніх запитів. У всіх сценаріях роботи з обліковими записами використовувалися фіктивні транспортні дані та вигадані дані.
• tools/check_site.py пройшов тестування при ширині екрану 320, 390, 768, 1024 та 1440 пікселів, із підшляхом до URL-адреси проєкту, переходом за допомогою клавіші Tab, успішним/відхиленим доступом до буфера обміну, зменшеною анімацією та вимкненим JavaScript. Не відбулося жодних невдалих запитів на ресурси чи зовнішніх запитів.
• tools/build_site.py створив 10 публічних файлів, що входять до списку дозволених, загальним обсягом близько 460 КБ. Знімки екрана браузера та квитанція містяться у файлі test-results/site/, який ігнорується.
• Wheel було успішно скомпільовано після встановлення інструментів setuptools/wheel, призначених лише для компіляції, у середовищі проєкту. Встановлення його в ізольоване цільове середовище та запуск tools/check_install.py пройшли успішно: статичні ресурси, контроль доступу, підписаний синтетичний експорт із 32 подіями та незалежно перевірене потокове завантаження.
• Пройшов перевірку pip check. Сканування шаблонів серед відібраних Git публічних кандидатів не виявило впізнаваних блоків приватних ключів, токенів GitHub/bot/AWS, довгих літеральних секретних присвоєнь або маркерів конфліктів злиття. Це не є доказом того, що відсутні всі можливі секретні формати. Зонди даних виконання/сеансу/ключів були проігноровані Git.
• Аутентифікація GitHub CLI була недійсною; не було налаштовано жодного віддаленого сервера, і не існувало жодного початкового коміту. Не було виконано жодного пушу, хостингу робочого процесу, розгортання Pages або релізу. Docker та кваліфікація Telegram/платформи в режимі реального часу залишаються поза межами цієї перевірки.

На цьому хості сталася помилка блокування завантаження Playwright у файловій системі робочого простору E:. Встановлення Chromium під %LOCALAPPDATA%/tgwitness-playwright та використання того самого PLAYWRIGHT_BROWSERS_PATH для перевірок пройшло успішно. Це обхідний шлях для середовища, а не зміна залежностей середовища виконання програми.

Інтерактивна документація та метадані веб-сайту · 29 жовтня 2026 року#

Публічний сайт складається з 12 англійських HTML-сторінок: головної сторінки, індексу посібників та десяти посібників. Артефакт містить 28 явно перелічених файлів презентації, обсягом приблизно 1,85 МБ, та не містить даних колектора. Публічний веб-сайт англійською мовою; переклади додатка та перекладені посібники репозиторію знаходяться окремо.

• Тести сайту, вихідної публікації та меж випуску: 18 пройшли, 2 пропущено. Пропуски стосуються створення символічних посилань у цій файловій системі Windows. Тести перевіряють унікальність метаданих сторінок, публічні сторінки лише англійською мовою, канонічні URL-адреси, усі записи в карті сайту , локальні ресурси/анкори, структуровану навігацію та виключення приватних файлів.
• І tools/check_site.py, і tools/check_docs_site.py пройшли тестування в Chromium при роздільній здатності 320, 390, 768, 1024 та 1440 пікселів у підшляху URL-адреси проєкту. Перевірки, передбачені в цьому посібнику, охоплюють усі 11 сторінок документації, пошук та навігацію за допомогою клавіатури, успішне/невдале копіювання в буфер обміну та читабельність вмісту без JavaScript.
• П’ять інтерактивних прикладів пройшли перевірку: відтворення/покрокове пересування/пауза/скидання повідомлень із зменшеною анімацією та призупиненням поза екраном; оригінальні/змінені/відновлені/укорочені ланцюжки хеш-кодів; рішення свідка щодо прийняття/відміни/розгалуження/відсутності відповіді; а також сценарії повної/затримки/відсутньої доставки; та карта розслідування, що пов’язує вигадані спостереження за перехресним чатом за ідентифікатором відправника, адресатом та хешем вкладення. Елементи управління розслідуванням пройшли перевірки на навігацію за допомогою клавіатури та резервне функціонування без JavaScript. Результати SHA-256 у браузері були незалежно порівняні з hashlib у Python та канонічним JSON. Приклад хешу також зберіг свій читабельний резервний варіант, коли Web Crypto був недоступний.
• Показники доставки та маркери діаграм відповідали таблиці, доступній для перегляду. Написи на осі для мобільних пристроїв було збільшено після візуального огляду. Кожен приклад позначено як ілюстративний або синтетичний, і жоден приклад у браузері не зв’язується з Telegram.
• Не було зафіксовано жодних зовнішніх запитів, невдалих HTTP-запитів або помилок JavaScript. Знімки екрану з настільних комп’ютерів та мобільних пристроїв, а також квитанції знаходяться під ігнорованими позначками test-results/site/ та test-results/docs-site/. Індекс документації, приклади повідомлень/хешів, макет «witness», діаграма доставки та карта розслідування були перевірені у форматах для настільних комп’ютерів та мобільних пристроїв.
• Перевірка публікації пройшла успішно для 282 файлів із відкритих джерел та 1 426 локальних посилань на документацію. Ruff успішно пройшов перевірку модифікованих інструментів та тестів сайту на Python.
• docs/HOW-IT-WORKS.md надає супровідний файл GitHub Markdown із діаграмами та формулами Mermaid . docs/INVESTIGATION.md охоплює весь об’єм облікового запису, збір історії за кожним чатом, профілі користувачів, перехресні посилання між чатами, хронології та передачу перевірених справ. Його етапи та обмеження були перевірені на відповідність поточним параметрам охоплення, збору даних, досьє, експорту, верифікатора та коду панелі. Розміщене на GitHub візуалізування не перевірялося.

Це перевірка локального веб-сайту/документації. Вона не додає активного статусу Telegram та не підтверджує розгортання хостованих сторінок, успішність віддаленого CI або індексацію у пошукових системах. Дивіться процедуру публікації та примітки щодо метаданих веб-сайту.