Головна/Завдання/Частина 1/ТЗ

Зоря. Частина 1: Вихід на зв'язок

Технічне завдання першого тижня. Результат тижня - ваш клієнт мережі Зоря.нет і реєстрація в просвіт. Далі йдуть жеребкування 2026-09-26 і частина 2 (правила гри та SDK) 2026-09-28. Поруч: легенда, специфікація клієнта, OpenAPI, оцінювання, календар.

1Що ви будуєте

Клієнт мережі Зоря.нет - ваш застосунок на React + TypeScript у вашому приватному репозиторії на GitHub. Через нього ви реєструєтеся, бачите статус доступу до репозиторію, отримуєте новини, особисті листи та наступні частини завдання. З нього ж виросте ігровий штаб у частині 3.

Видається: цей пакет, контракт API в OpenAPI 3.1, живий сервер мережі в режимі ефіру з 2026-09-21 і навчальний стенд. Не видається: SDK, опис гри, готовий клієнт. Вбудований вебклієнт сервера для учасників закритий.

Обов'язковий мінімум клієнта: реєстрація; отримувач запрошення й статус доступу до репозиторію; опитування сповіщень; читання частин завдання. Реєстрація потрібна в просвіт, решта - до виходу частини 2 (2026-09-28): вона приходить у мережу частиною завдання. Інше в специфікації позначено як рекомендація (специфікація, розділ 1).

Реєстрація будь-яким HTTP-клієнтом зараховується. Запит із curl, Postman чи скрипта сервер не відрізняє від запиту вашого застосунку й не намагається відрізняти. Це не лазівка: сам клієнт у частині 1 не перевіряється, його перевіряє оцінювання штабу пізніше, за документом оцінювання. Клієнт, якого немає, не покаже частину 2 і не стане штабом.

  ваш клієнт (браузер або Node)            сервер Зоря.нет
  +----------------------------+  HTTPS   +--------------------------+
  | реєстрація, статус,        | -------> | /api/v1: ефір, акаунт,   |
  | новини, листи, частини     | <------- | новини, листи, частини   |
  +----------------------------+ опитув.  +------------+-------------+
                                                       | бот допуску
  ви --- запрошення ---> ваш репозиторій <-- читання --+
         (GitHub)        + файл .zoria

2Тиждень: від публікації до частини 2

Від публікації сервер працює в режимі ефіру. До просвіту він шумить: майже всі відповіді - перешкоди, зрідка проходить справжній кадр із печаткою станції. У легенді це вихід на зв'язок: мережа мовчить під Шумом, і тільки станція пробивається крізь перешкоди. За 6 годин до просвіту в шумі проступає зв'язок: несуча, потім позивні, потім станція на частоті. Технічно це провісник - поле harbinger у кожному справжньому кадрі: opensIn, точна кількість секунд до відкриття, і text, голос станції українською й англійською, без чисел. Якщо клієнт слухав ефір і провісника не було, найближчі 6 годин просвіту не буде.

 2026-09-21            початок просвіту: 2026-09-24 05:00 - 2026-09-25 09:00     09-26         09-28
     |                                     |                                       |             |
     v                                     v                                       v             v
   [ шум ......................| провісник 6 год | ПРОСВІТ, не менше 10 год | після ] жеребкування частина 2
     перешкоди, печатка,         строк відкриття   перешкод немає,          реєстрацію
     глушіння; реєстрації немає  у кадрах          реєстрація відкрита      закрито

Два проходи очима учасника.

Вручну:

1. До просвіту ви відкриваєте клієнт раз на кілька годин, не рідше ніж раз на 10 годин.
2. Клієнт показує шум, із провісником - відлік у вашому місцевому часі.
3. У просвіт ви вводите логін, відображуване ім'я, пароль, код заявки і свій приватний репозиторій.
4. Клієнт показує, кого запросити; ви запрошуєте й кладете .zoria.
5. За кілька хвилин статус стає verified, приходить лист.

Автоматично:

1. Клієнт слухає GET /ether не частіше ніж раз на 15 с і перевіряє печатку.
2. З провісника він знає момент відкриття: at кадру плюс opensIn.
3. На першому справжньому кадрі з phase: "window" він надсилає заготовлену заявку.
4. Відповідь 429 authentication-busy означає, що черга перевірки паролів зайнята: почекати Retry-After секунд і повторити заявку. Це не відмова і до ліміту адреси не йде.
5. Якщо відповідь загублено, він входить тими самими логіном і паролем, а не реєструється вдруге.
6. Далі він опитує зведення й показує статус доступу.

3Дати й адреси

Київський час у ці дати - UTC+3.

4Вимоги допуску

Оновлено 22.09: порядок і поля - в оголошеннях.

5Приймання

Частину 1 приймає машина за двома умовами:

1. Реєстрація відбулася в просвіт. Поза просвітом акаунт створити не можна, тож умову виконано, якщо акаунт є.
2. До строку підтвердження доступу статус репозиторію - verified (P1-06).

Де це видно:

• GET /me/repository: accessStatus, reason, checkedAt;
• лист із notice.type: "repository" на кожну зміну статусу чи причини;
• GET /ether/roll: ваш номер під вашим відображуваним ім'ям.

verifiedElsewhere: true означає, що той самий репозиторій уже підтверджено за іншим акаунтом, і ваша заявка підтвердитися не може: перевірте .zoria і зверніться до організаторів.

Після виправлення бот переглядає заявку сам: під час зміни заявки або чергового читання .zoria, не рідше ніж раз на 10 хвилин. Рішення організатора бот не переглядає. Строк виправлення - той самий строк підтвердження доступу.

Балів частина 1 не дає. Її підсумок - місце в жеребкуванні та допуск до наступних частин.

6Вибування і збій на нашому боці

Вибуває учасник:

• який не зареєструвався в просвіт;
• чий доступ не підтверджено до строку з календаря;
• знятий за розділом "Чесна гра" документа оцінювання.

Збій на нашому боці. Якщо за час просвіту за нашим моніторингом сумарно понад 30 хвилин GET /ether не віддавав справжніх кадрів або реєстрація відповідала 5xx, просвіт подовжується на сумарну тривалість збою. Новий кінець приходить у полі window.closesAt кадру ефіру; подовження оголошується на сайті й новиною в мережі. Збій сумарно на 30 хвилин і менше просвіт не подовжує.

Про збій пишіть в офіційний канал із часом в UTC і значенням заголовка X-Request-Id відповіді.

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

7Що далі

Жеребкування 2026-09-26. Публікується перестановка всіх зареєстрованих, виведена із солі жеребкування. Схема - commit-reveal із публічним маяком випадковості drand: 2026-09-21 публікується хеш секрету організаторів (буде опубліковано 21.09); сіль - SHA-256 від секрету та значення маяка drand на заздалегідь оголошений раунд після просвіту; на жеребкуванні секрет розкривається, і перестановку може перерахувати кожен. Групи нарізаються з цієї перестановки пізніше. Правило й спосіб перевірити свою групу - оцінювання, дати - календар. Результат жеребкування приходить у клієнт новиною.

Частина 2, 2026-09-28. Правила гри, SDK, протокол, шаблон бота і наказ. Частина з'являється в списку частин завдання (GET /stages); клієнт дізнається про неї за лічильником releasedStages у зведенні GET /me/summary.

8Поза частиною 1

• Гра, її правила, SDK, бот, ігрові функції штабу.
• WebSocket і push-сповіщення: обмін тільки опитуванням.
• Готовий клієнт: вбудований вебклієнт сервера закритий.
• Бали.

9Питання учасників

Відповіді на часті питання зібрані окремою сторінкою: часті запитання. Там же - що означають найчастіші відповіді сервера.