The post has been translated automatically. Original language: Russian
The demo opens for its author but refuses access to a judge. Someone posts “the project doesn't work,” although the reviewer has not reached the scenario itself. Turning that message straight into a competition score makes an access problem into an unsupported conclusion about the solution.
Technical acceptance needs a more precise result: which version was checked, which permissions were used, what was observed, and where the check stopped. The process below is for organizers and developers. It produces a check record; the judges score the competition criteria separately.
1. Record the version and the time
Before submissions open, publish the required artifacts, the deadline with its time zone, the accepted fallback method, and the repair procedure. Assign an acceptance coordinator. Reviewers need to know who receives a question when an artifact is inaccessible and the submission deadline has passed.
In the submission card, save the full commit ID, a link to the README at that version, the submission time, and the check time. Include the date, time, and time zone or UTC offset. These timestamps distinguish the original submission from later access restoration. A time without its date and zone cannot explain that sequence.
A link to the main branch can start showing a different file. Use a link to the specific commit for the README. GitHub's permanent-link documentation describes a shortcut: press Y while viewing the file. Separately record which version is deployed in the demo; a source link does not establish that relationship.
2. Check access with the assigned role
Our fictional exercise concerns a private demo that processes synthetic applications. The organizer replaces the assigned reviewer before the check. The previous role retains access, while the new one is refused. All circumstances and results here are invented for practice, rather than drawn from a real event.
Use the authorized account of the new reviewer. An author or administrator session hides the problem. Open the required artifacts one at a time: the repository, README, demo, and any specified recording. Record the access failure and the expiry of temporary permissions. Do not make a private project public to bypass an error.
In this exercise, the demo stops the check at sign-in. A recording shows the main screen, but does not confirm processing on the new reviewer's input. Record that limitation. If the rules accept the recording as a fallback, describe it separately; it does not turn untested execution into confirmed execution.
3. Name the specific state
Replace “doesn't work” with a state that describes what was observed:
- access_blocked: the assigned reviewer could not open a required artifact. Name the artifact or access step.
- runtime_unconfirmed: the materials are accessible, but scenario execution could not be confirmed. Name the unconfirmed execution step.
- partial: part of the documented scenario was checked, but a remaining step stopped. Identify the boundary of the checked part.
- reproduced: the documented scenario completed in the recorded environment. This confirms that scenario, rather than the readiness of the entire product.
Use access_blocked for our private-demo exercise. Its cause may still need clarification. A sign-in refusal does not prove that the algorithm is wrong. The status preserves that distinction for the person making a later decision.
For reproduced, blocked_at must be null. Other states require a specific stopping point in that field. Describe the actual result separately in observed: a status without an observation leaves too much room for guessing.
4. Build the 15-field record
The submission acceptance checklist includes a record template. Fill in its fields in groups:
- submission_id and commit: the submission identifier and full identifier of the version under review.
- environment, route, and input: the environment, check method, and reference to a safe input sample.
- steps, expected, and observed: the steps performed, expected result, and actual result.
- blocked_at, evidence, fallback, and status: the stopping point, evidence references, fallback material, and state.
- next_action, responsible_role, and approval_reference: the specific action, responsible role, and reference to an authorized decision, or null.
Submission and check timestamps remain in the linked submission card; the local validator does not check them. Do not add arbitrary fields to its JSON. steps and evidence must be non-empty arrays of strings. Restricted evidence references locate the basis for an observation without copying the raw log into the record.
For our exercise, next_action could read: “The coordinator checks whether access can be restored for the new assigned role without changing the submitted version.” That is not yet an approval. Until a decision is made, approval_reference stays null. The responsible person receives a specific question rather than a request to “fix everything.”
5. Validate the structure locally
The open Stavleak acceptance kit contains acceptance.mjs and a fictional example-record.json. Use the validator code from that kit. Copy the example into a private working file outside the public repository, replacing every value with the result of a human check. The example commit is fictional too.
Use Node.js 22 or newer. Put a copy of our validator and private-record.json in a separate private working directory. Then run only the record check:
node acceptance.mjs validate private-record.json
This command reads the JSON and checks its structure and consistency. It does not open links, run a participant repository, test access, or assign scores. No package installation or network connection is needed. It checks the full commit ID as a hexadecimal string of 40 or 64 characters, but does not establish that the commit exists.
Exit code 0 means the structure is valid. Code 1 reports an incomplete or inconsistent record; code 2 means unreadable JSON or invalid arguments. Correct the record and run the command again. Even a JSON file that passes can contain an inaccurate observation; a person must check the truth of the record.
6. Approve repairs under the rules
Restoring access and changing code require separate decisions. After the deadline, the coordinator follows the published procedure, saving the approval reference and original materials. Do not replace the submitted commit with a new build outside that procedure.
If access restoration is approved in our exercise, preserve the original access_blocked record and create a linked recheck record. Verify the version, open its README, and follow the permitted scenario. For local execution, use a disposable environment without production secrets or host-folder mounts; inspect installation commands first. Record any author assistance needed.
Do not publish tokens, passwords, personal data, or raw logs in acceptance records. Store them in the approved restricted location and use an authorized reference or identifier in evidence. An access-error screenshot may also need unrelated details removed.
7. Tell the judges what was checked
The judges receive the submitted version, acceptance state, observations, and unresolved questions. reproduced does not mean the highest score. access_blocked does not automatically mean zero. Admission, the consequences of missing materials, and competition scoring follow the published rules and the authority assigned to each role.
Leave a clear record for the next person: what was checked, what remains unknown, what action is assigned, and who owns it. A change of reviewer can then be handled without reconstructing the history from messages saying “it opens for me.”
Демо открылось у автора и закрылось у судьи. В чате появляется «проект не работает», хотя проверяющий ещё не дошёл до выполнения сценария. Если такую фразу сразу перенести в конкурсную оценку, проблема доступа станет неподтверждённым выводом о качестве решения.
Технической приёмке нужен более точный результат: какую версию проверяли, с какими правами, что удалось наблюдать и на каком шаге возникла проблема. Ниже процесс для организатора и разработчика. Он заканчивается протоколом проверки; баллы по критериям жюри выставляет отдельно.
1. Зафиксируйте версию и время
До открытия сдачи опубликуйте обязательные материалы, дедлайн с часовым поясом, допустимый резервный способ проверки и порядок исправлений. Назначьте координатора приёмки. Проверяющий должен знать, кому передать вопрос, если материалы недоступны, а время сдачи уже прошло.
В карточке заявки сохраните полный идентификатор коммита, ссылку на README этой версии, время сдачи и время проверки. Указывайте дату, время и часовой пояс или смещение UTC. Эти отметки помогут отличить первоначальную сдачу от последующего восстановления доступа. Одно время без даты и зоны этого не объясняет.
Ссылка на ветку main может начать показывать другой файл. Для README используйте ссылку на конкретный коммит. В документации GitHub о постоянных ссылках описан короткий способ: при просмотре файла нажать Y. При этом отдельно запишите, какая версия размещена в демо; ссылка на исходники сама по себе её не подтверждает.
2. Проверяйте доступ назначенной ролью
Учебный сценарий: команда сдала закрытое демо обработки синтетических заявок. Перед проверкой организатор заменил назначенного проверяющего. У прежней роли доступ есть, новая получает отказ. Все обстоятельства и результаты этого примера вымышлены; это упражнение, а не история реального события.
Проверяйте под разрешённой учётной записью нового проверяющего. Сессия автора или администратора скрывает проблему. Откройте обязательные материалы по очереди: репозиторий, README, демо и предусмотренную запись. Запишите точку отказа и срок временного доступа. Не делайте закрытый проект публичным ради обхода ошибки.
В нашем упражнении демо остановило проверку на входе. Запись показывает основной экран, но не подтверждает обработку ввода нового проверяющего. Так и запишите. Если регламент допускает этот материал как резервный, укажите его отдельно; он не превращает непроверенный запуск в подтверждённый.
3. Назовите конкретное состояние
Вместо общего «не работает» выберите состояние, которое описывает наблюдение:
- access_blocked: назначенный проверяющий не смог открыть обязательный материал. Укажите материал или шаг доступа.
- runtime_unconfirmed: материалы доступны, но выполнение сценария подтвердить не удалось. Укажите неподтверждённый шаг запуска.
- partial: часть описанного сценария проверена, оставшийся шаг остановился. Запишите границу проверенной части.
- reproduced: описанный сценарий завершился в записанной среде. Это подтверждает именно этот сценарий, а не готовность всего продукта.
В учебном случае с закрытым демо используем access_blocked. Причина ещё может требовать уточнения. Отказ на входе не доказывает, что алгоритм ошибается. Статус сохраняет это различие для человека, который позже будет принимать решение.
Для reproduced поле blocked_at должно быть null. Для остальных состояний оно называет конкретную точку остановки. Отдельно опишите фактический результат в observed: статус без наблюдения оставляет слишком много места для догадок.
4. Соберите запись из 15 полей
У чек-листа технической приёмки есть шаблон записи. Его поля удобно заполнять группами:
- submission_id и commit: идентификатор заявки и полный идентификатор проверяемой версии.
- environment, route и input: среда, способ проверки и ссылка на безопасный входной пример.
- steps, expected и observed: выполненные шаги, ожидаемый и фактический результат.
- blocked_at, evidence, fallback и status: точка остановки, ссылки на материалы проверки, резервный материал и состояние.
- next_action, responsible_role и approval_reference: конкретное действие, ответственная роль и ссылка на разрешённое решение либо null.
Времена сдачи и проверки остаются в связанной карточке заявки: локальный валидатор этих отметок не проверяет. Не добавляйте произвольные поля в его JSON. В steps и evidence нужны непустые массивы строк. Ссылки на закрытые материалы позволяют найти основание, не копируя сам лог в протокол.
Для нашего упражнения next_action можно сформулировать так: «Координатор проверяет, разрешено ли восстановить доступ новой назначенной роли без изменения сданной версии». Это ещё не разрешение. До решения approval_reference остаётся null. Ответственный получает конкретный вопрос, а не просьбу «починить всё».
5. Проверьте структуру локально
В открытом acceptance kit Stavleak есть acceptance.mjs и вымышленный example-record.json. Возьмите код валидатора из этого набора. Скопируйте пример в закрытый рабочий файл вне публичного репозитория и замените каждое значение результатом человеческой проверки. Примерный коммит также вымышленный.
Нужен Node.js 22 или новее. Разместите копию нашего валидатора и private-record.json в отдельном закрытом рабочем каталоге. Затем выполните только проверку записи:
node acceptance.mjs validate private-record.json
Команда читает JSON и проверяет его структуру и согласованность. Она не открывает ссылки, не запускает репозиторий участника, не проверяет доступ и не ставит баллы. Установка пакетов и сеть не требуются. Полный идентификатор коммита проверяется как шестнадцатеричная строка из 40 или 64 символов, но наличие такого коммита валидатор не устанавливает.
Код завершения 0 означает корректную структуру. Код 1 сообщает о неполной или противоречивой записи, код 2 о нечитаемом JSON либо неверных аргументах. Исправьте запись и повторите команду. Даже успешно проверенный JSON может содержать ошибочное наблюдение; его достоверность проверяет человек.
6. Разрешайте исправление по регламенту
Восстановление доступа и изменение кода требуют разных решений. После дедлайна координатор применяет опубликованный порядок, сохраняет основание разрешения и первоначальные материалы. Не подменяйте сданный коммит новой сборкой без предусмотренной процедуры.
Если в учебном сценарии восстановление доступа разрешили, сохраните первоначальный access_blocked и создайте связанную запись повторной проверки. Сверьте версию, откройте README и пройдите разрешённый сценарий. При локальном запуске используйте одноразовую среду без рабочих секретов и подключённых папок основной системы; сначала прочитайте команды установки. Запишите помощь автора, если она понадобилась.
В протоколах не публикуйте токены, пароли, личные данные и исходные логи. Храните их в согласованном закрытом месте, а в evidence оставляйте разрешённую ссылку или идентификатор. Скриншот отказа также может потребовать удаления лишних деталей.
7. Объясните жюри, что проверено
В результате жюри получает сданную версию, состояние приёмки, наблюдения и незакрытые вопросы. reproduced не означает максимальную оценку. access_blocked не превращается автоматически в ноль. Допуск, последствия отсутствующих материалов и конкурсная оценка определяются опубликованными правилами и полномочиями ответственных.
Проверяющий оставляет следующему человеку ясную запись: что проверено, что осталось неизвестным, какое действие назначено и кто за него отвечает. Это позволяет продолжить работу после смены роли, не восстанавливая историю по сообщениям «у меня всё открывается».
Share
