Submission package и repro audit

1. Защиту решает пакет, а не речь

Перед защитой легко скатиться в школьную логику: главное — хорошо выступить. В инженерии жёстче: сначала смотрят на то, что проверяется руками. Reviewer открывает репозиторий, упирается в пустой README, битую команду запуска и файл final_final_v2.md — и доверие проседает ещё до вашего первого слова.

Submission package — это не один репозиторий и не одна ссылка на демо. Это набор артефактов, которые вместе отвечают: что вы сделали, как это запустить, что именно проверили и где границы проекта. Удобно думать о нём как о папке сдачи инженерной работы: сам объект плюс паспорт, инструкция, журнал работ и пометки о том, что пока не доведено до production.

Всё это особенно важно в AI-assisted разработке. Когда в работе участвовал Claude Code, reviewer'у нужен traceability: где постановка задачи, где evidence, где запуск проверок, где ваше решение, а где помощь инструмента. Package собирают из уже существующих артефактов, а не сочиняют задним числом.

Ниже полезно держать в голове очень простую схему:

flowchart TD
    A[Репозиторий] --> B[README и setup]
    B --> C[SPEC.md]
    C --> D[EVIDENCE.md]
    D --> E[Tests и checks]
    E --> F[Demo / screenshots / video]
    F --> G[Known limitations]
    G --> H[Доверие reviewer]

Если хотя бы одно звено выпадает, вся цепочка начинает шататься. Проект может быть неплохим, но впечатление будет примерно как от кухни без инструкции по сборке: детали хорошие, а где дверь, где стенка — догадайтесь сами.

2. Из чего собран сильный package

Самая частая ошибка на этом этапе — думать, что package надо дописывать с нуля. На деле почти всё основное у вас уже есть из предыдущих модулей. Задача — собрать это в непротиворечивую структуру, чтобы reviewer за пару минут понял, куда смотреть и в каком порядке.

Вот практичный ориентир для структуры:

my-capstone/
  README.md
  SPEC.md
  EVIDENCE.md
  DEMO.md
  TEST_PLAN.md
  .env.example
  ARCHITECTURE.md
  MIGRATION.md
  ROLLBACK_PLAN.md

Часть этих файлов обязательна почти для любого capstone, часть зависит от формата проекта. Удобно видеть это в таблице.

README.md

SPEC.md

EVIDENCE.md

DEMO.md

README

TEST_PLAN.md

.env.example

ARCHITECTURE.md

MIGRATION.md

ROLLBACK_PLAN.md

RISK_MAP.md

COMPATIBILITY_MATRIX.md

Если у вас MVP, package обычно строится вокруг

README

SPEC.md

EVIDENCE.md

MIGRATION.md

Очень важен

README

Вот компактный каркас, который обычно работает:

## Быстрый старт

1. Скопируйте `.env.example` в локальный env-файл
2. Установите зависимости
3. Запустите проект командой из этого раздела
4. Откройте сценарий из `DEMO.md`
5. Выполните команды проверки из раздела `Проверка`

Команды в вашем проекте будут свои — где-то docker compose up, где-то npm run dev, где-то ./gradlew bootRun, где-то uvicorn. Важны не названия, а то, что по этим шагам реально можно стартовать с чистого состояния — без шаманства и телепатии.

3. Reproducibility audit: пять вопросов доверия

Reproducibility audit звучит слегка торжественно, но по сути это очень земная вещь. Вы берёте свой capstone и проверяете: пройдёт ли посторонний человек путь от клона репозитория до core flow по документам внутри проекта — без ваших устных пояснений, без переписки в чате.

Главная сила этого аудита в том, что он закрывает сразу пять вопросов доверия:

README.md

SPEC.md

.env.example

TEST_PLAN.md

EVIDENCE.md

README

Здесь ключевое слово — согласованность. Если в

SPEC.md

README

Именно поэтому reproducibility audit — это trust mechanism, а не косметика: reviewer доверяет не вашей уверенности, а маршруту проверки.

Хорошая новость в том, что аудит почти всегда находит не «фатальную катастрофу», а мелкие разрывы: где-то нет команды, где-то demo-шаг устарел, где-то limitations живут у вас в голове, а не в репозитории. И лучше вы поймаете это сами, чем mentor на защите.

4. Прогон на чистом окружении

Самый полезный способ провести аудит — сыграть в «чужого человека». Открыть не свой рабочий каталог с настроенными зависимостями, а свежий клон, и пройти только по маршруту из package. Если запуск требует знания, которого нет в

README

Правило прогона простое: не подглядываете в старый терминал, не берёте команды из памяти, не правите документацию по ходу, пока не зафиксировали проблему. Иначе выйдет не аудит, а мягкая самоиндульгенция.

Шаблон такого прогона может быть очень простым:

git clone <repo-url> capstone-check
cd capstone-check
cp .env.example .env.local     # если проект использует env-файл
<команда установки зависимостей>
<команда запуска проекта>      # приложение должно стартовать без ручных правок
<команда проверок>             # ожидаем зелёный результат

Если у вас контейнерный проект, вы, скорее всего, будете использовать docker compose up -d. Java-проект — ./gradlew test или ./gradlew bootRun. Python — pip install -r requirements.txt и запуск сервиса. Конкретика зависит от формата capstone, логика одна: все критичные шаги видны изнутри package.

Отдельно важно прогнать core flow, а не только технический запуск: зелёная сборка — не финиш. Если в

DEMO.md

.claude

Очень помогает фиксировать находки сразу — в таблицу или заметку: «шаг 3 непонятен», «не хватает версии Node», «команда запуска в README устарела», «скриншот не соответствует интерфейсу». Это не мелочи: из них складывается впечатление «проекту можно доверять» или «автор в последний раз запускал это только у себя».

5. README, EVIDENCE.md и known limitations

Есть три файла, которые недооценивают особенно часто:

README.md

EVIDENCE.md

README.md

EVIDENCE.md

Не менее важны known limitations. Новички часто боятся их писать — кажется, будто это признание слабости. На деле всё наоборот: отсутствие ограничений выглядит подозрительно. Границы есть у любого capstone: демо-режим вместо боевой авторизации, отсутствие retry, поддержка только CSV, непокрытые edge cases, локальный запуск без production deployment. Назвали честно — и reviewer видит: автор понимает реальный объём проекта и не продаёт прототип как космический корабль.

Простой и сильный шаблон:

## Известные ограничения

- поддерживается только один core-сценарий, описанный в `DEMO.md`;
- авторизация заменена демо-режимом и не предназначена для production;
- отчёты проверены на тестовых данных;
- retry для внешнего API пока не реализован.

Обратите внимание: здесь нет ни оправданий, ни драматизма, ни «не судите строго». Только факты. Именно такой тон и создаёт доверие.

Сюда же относится и финальная гигиена публикации. В package не должно быть реальных

.env

Когда package собран правильно, с ним происходит приятная вещь: проект начинает держаться сам. Его можно открыть без вас, запустить без звонка автору, проверить без гадания и оценить без скидки на хаос. Это и есть главный признак готовности к защите — не «устал и хочу нажать сдать», а «внешний человек дойдёт от репозитория до результата и не потеряет к вам доверие по дороге».

1

Задача

Claude code, 32 уровень, 0 лекция

Недоступна

Инвентаризация submission package из терминала

Инвентаризация submission package из терминала

Открыть

1

Задача

Claude code, 32 уровень, 0 лекция

Недоступна

Документ reproducibility audit для capstone package

Документ reproducibility audit для capstone package

Открыть