Проверки перед показом

После m13 JobTrack уже не выглядит игрушкой.

Вакансии добавляются, данные не исчезают молча, export JSON есть, границы хранения записаны, и перед тем как показывать JobTrack, я почти готов сказать: можно показывать.

И тут вылезает список неприятных вопросов.

— что видно в названии вкладки и при шаринге; — дефолтный favicon, пустой description, мусорный title; — проходят ли сборка, type-check и тесты; — debug-следы, мёртвый код, лишние зависимости; — утечки в export JSON: secrets, session data, лишние поля; — длинные вакансии, которые ломают экран; — проходится ли сценарий с клавиатуры и на mobile.

Это не новая фича. Это аудит: SEO, качество кода, безопасность перед первым нормальным показом.

Плохой prompt тут выглядит полезным:

Проверь проект и исправь всё, что найдёшь.

Слишком широко. Агент за один заход поменяет SEO, перепишет UI, притащит новую библиотеку, поправит тесты и залезет в storage. На экране стало лучше, а я уже не понимаю, что изменилось и зачем — потерял контроль над diff.

Перед первым показом нужен не ремонт всего подряд, а аудит без правок: сначала список проблем, из него — must-fix, и только их я чиню точечно.

Короче, правило простое: увидел слишком много изменений — стоп. Scope расползся — сузить заново, потом дальше.

Зачем нужен этот модуль

Проверки перед показом — это не ещё один этап разработки и не про новую функцию.

К этому моменту JobTrack прошёл весь путь: от discovery до data boundaries. Новую функцию я не придумываю, MVP не расширяю. Задача теперь другая — поймать скрытые риски перед первым показом.

Пользователь не увидит архитектуру. Он увидит странный title, сломанный mobile, неработающий build, случайный debug-текст, лишние данные в export JSON или поле ввода, которое ломает интерфейс. И это уже не техдолг. Это выглядит так, будто продукту нельзя доверять.

Короче, модуль 14 — промежуточная проверка перед Definition of Done. Я тут не принимаю MVP финально. Я собираю audit report и чиню только то, что блокирует нормальный первый показ. В SPP это делает скилл-чекпоинт pre-show-audit внутри фазы 6.

SPP держит память о проекте в docs/spp/pipeline-state.md: что за продукт, что сделано, какие решения приняты. Поэтому работу можно прервать и продолжить в новой сессии. Следующий модуль — это следующая фаза того же pipeline.

Почему сначала audit report

Потому что prompt в духе проверь и исправь всё — опасная штука. Он смешивает поиск проблем и правки. Агент может найти 20 замечаний, исправить 12, добавить 3 новые идеи и случайно поменять то, что уже работало.

Сначала audit report, без единой правки. Потом я выбираю, что из этого must fix before demo. И только после этого агент лезет в код чинить выбранное. А если правок вдруг набралось слишком много — стоп, пересобираем scope.

Смысл один: не дать последнему осмотру превратиться в новый цикл разработки.

SEO и sharing baseline

Что я смотрю перед показом.

SEO и sharing baseline. Снаружи MVP должен выглядеть как продукт, а не как заглушка: title отражает продукт, description не пустой и не обещает лишнего, favicon не дефолтный, OG title/description/image на месте или записано, почему их пока нет. Robots и sitemap не врут, если проект уже публичный.

Публичный URL обычно появляется только в модуле 15, на первом деплое. Поэтому здесь я проверяю SEO на будущее или на локальном demo, а не требую готовую ссылку прямо сейчас. Для локального demo нормально написать прямо: публичного SEO пока нет, показываю экраном или локальной ссылкой.

Quality gates

Quality gates. Обычно хватает tests, type-check, build и lint — если lint в проекте есть. Команды нет — не выдумывай её. Запиши, что отдельного lint/build/test тут нет, и чем это закрыто: manual fallback, smoke check, clean run. Зелёные проверки не доказывают, что продукт полезен. Зато красные почти всегда значат, что показывать рано.

Code quality audit

Code quality audit — короткий осмотр, не ревью архитектуры на три дня. Смотрю: нет ли мёртвого кода после прошлых итераций, случайных зависимостей, console.log, debug text, временных флагов, тестовых данных в UI. Плюс TODO без owner, дубли важных значений вроде статусов и источников, и не пролезла ли новая функция мимо scope. Задача — вымести мусор перед показом. Не затевать большой refactor из-за того, что агенту попался уродливый файл.

Security audit

Security baseline. Даже локальный MVP не должен течь данными. Проверяю: .env, ключи, токены, credentials не уехали в Git. secrets не утекли в клиентский код. Пользовательский ввод не вставляется как HTML без защиты, а поля title, company, notes, nextStep не открывают очевидный XSS. Отдельно — export JSON. В нём не должно быть токенов, session data, debug dumps и stack traces. Внешние ссылки — открываются безопасно. README не просит юзера пихать секреты в prompt к ИИ.

Это не pentest. Это baseline. Который всё равно лучше, чем надежда, что до маленького MVP никто не доберётся.

UX/accessibility smoke

UX/accessibility smoke. Перед показом важна не красота, а проходимость сценария: основной путь живой на mobile width, длинные названия вакансий и компаний не ломают layout, empty state понятен, error state есть или его нет — если сценарию он не нужен. Фокус виден при keyboard navigation. У кнопок и полей — понятные labels. Текст не наезжает на соседние элементы. И если storage локальный — юзер это понимает. Полный accessibility audit оставляю на потом. Базовые косяки перед показом ловлю сразу.

Must fix и backlog v2

Находки после аудита раскладываю на две кучи.

Must fix before demo — всё, что ломает запуск или основной сценарий, грозит утечкой данных, портит export, мешает понять продукт или делает публичную ссылку явно сырой.

Backlog v2 — nice-to-have polish, будущие SEO-улучшения, большая accessibility-доработка, refactor без пользовательского эффекта и новые функции.

Главная ошибка — чинить всё подряд. Модуль 14 не расширяет MVP. Его дело — снять риски перед m15.

Если изменений слишком много

Простое правило, если ты не разработчик: агент после аудита предлагает слишком много правок — тормози. Читать каждую строку кода не нужно. Достаточно сказать:

Слишком много изменений для одного шага.
Раздели результат на:
1. must fix before demo;
2. можно отложить в backlog v2;
3. не надо делать сейчас.
Код пока не меняй.

Если агент уже внёс много правок, не проси его продолжать чинить всё подряд. Сначала попроси короткое резюме: что изменилось, зачем, какие проверки надо повторить. Объяснение мутное — откатывай или зови того, кто в коде разберётся.

Гора внезапных правок прямо перед показом — уже повод насторожиться. Никакого геройского допиливания. Стоп — и scope снова у тебя в руках.

Цель практики — проверить твой проект перед финальной приёмкой: SEO/sharing, качество кода, безопасность, UX/accessibility smoke. Не добавляй новые функции. Сначала аудит, потом только подтверждённые must-fix.

Шаг 0. Запусти audit workflow

Начни с SPP и запрети правки до отчёта:

Используй /spp.

Мы на модуле 14. Мой проект уже прошёл m13: данные имеют storage decision и JSON export.

Нужно провести аудит перед показом:
- SEO/sharing baseline;
- quality gates;
- code quality;
- security baseline;
- UX/accessibility smoke.

Сначала сделай audit report без правок.
Не меняй код, тексты, зависимости, storage, export JSON и UI.
После отчёта раздели находки на:
1. must fix before demo;
2. backlog v2;
3. не делать сейчас.

Шаг 1. Проверь SEO и sharing

Полный SEO/sharing-чеклист живёт в одном месте — в дополнительном материале «SEO baseline для MVP». Здесь прогони его, а не переписывай заново. Попроси агента проверить:

• title;
• description;
• favicon;
• OG title/description/image;
• robots/sitemap, если проект уже публичный;
• public URL или честный local demo mode (публичный URL обычно появляется только после деплоя в модуле 15).

Prompt:

Проверь SEO и sharing baseline для моего проекта.

Код не меняй.

Верни таблицу:
| Проверка | Сейчас | Риск | Рекомендация |

Проверь:
- title;
- description;
- favicon;
- OG title/description/image;
- robots/sitemap, если применимо;
- public URL или local demo mode.

Не обещай SEO для публичного поиска, если MVP показывается локально.

Шаг 2. Проверь quality gates

Запусти доступные команды проекта. Для типичного JS/TS проекта:

npm test
npm run type-check
npm run build
npm run lint

Если команды нет, не выдумывай. Запиши, что именно отсутствует. Несуществующий script в отчёте — это не качество, а театр.

Prompt:

Проверь quality gates проекта.

Сначала найди доступные npm scripts.
Запусти только существующие проверки:
- tests;
- type-check;
- build;
- lint, если есть.

Верни:
- команда;
- результат;
- если команда отсутствует, чем это покрыто сейчас;
- что блокирует demo.

Шаг 3. Проведи code quality audit

Попроси короткий осмотр без большого refactor:

Проведи code quality audit моего проекта.

Код не меняй.

Проверь:
- мёртвый код;
- случайные зависимости;
- debug-текст, console.log и временные флаги;
- устаревшие TODO без решения;
- дублирование статусов, источников и других важных значений;
- функции, которых нет в MVP scope.

Верни только проблемы, которые могут помешать первому показу.
Большой refactor отправляй в backlog v2.

Шаг 4. Проведи security audit

Проверку JSON export на секреты подробно ты уже делал в модуле 13 — здесь повтори её, а не описывай заново. Проверь baseline безопасности:

Проведи security audit для текущего MVP.

Код не меняй.

Проверь:
- .env, ключи, токены и credentials не попали в Git;
- secrets не попали в client-side код;
- пользовательский ввод не вставляется как HTML;
- нет очевидного XSS-риска в title, company, notes, nextStep;
- export JSON не содержит secrets, session data, debug dumps и stack traces;
- README не просит вставлять персональные данные или secrets в prompt к ИИ.

Раздели находки на must fix before demo и backlog v2.

Шаг 5. Проведи UX/accessibility smoke

Это не полный аудит доступности. Это быстрый проход перед показом.

Проверь:

• mobile width;
• keyboard/focus;
• длинные названия вакансий и компаний;
• empty state;
• error state или честное отсутствие error state;
• понятные labels у кнопок и полей;
• текст не перекрывает другие элементы;
• локальное хранение данных объяснено, если оно выбрано в m13.

Prompt:

Проведи UX/accessibility smoke для моего проекта.

Код не меняй.

Проверь основной сценарий:
- открыть приложение;
- добавить вакансию;
- увидеть её в списке;
- изменить status или notes;
- сделать JSON export.

Отдельно проверь:
- mobile width;
- keyboard/focus;
- long text;
- empty/error states;
- labels.

Верни список must fix before demo и backlog v2.

Шаг 6. Раздели must fix и backlog v2

Создай docs/release.md — это журнал приёмки и релиза проекта. Здесь живут audit report и, начиная с модуля 15, Definition of Done и результаты финальной приёмки. Задачи остаются в docs/todo.md, а docs/release.md фиксирует, что и когда проверено.

Собери общий audit report в docs/release.md:

## Audit before demo

### Quality gates
- npm test: ...
- npm run type-check: ...
- npm run build: ...
- npm run lint: ...

### Must fix before demo
- ...

### Backlog v2
- ...

### Not now
- ...

Must fix — только то, что блокирует показ или создаёт риск. Всё остальное уходит в backlog v2.

Шаг 7. Исправь только подтверждённые must-fix

Теперь можно разрешить агенту правки, но только выбранные:

Исправь только подтверждённые must-fix пункты из audit report.

Не добавляй новые функции.
Не меняй storage decision и export JSON format без отдельного решения.
Не добавляй зависимости без объяснения и подтверждения.
Не делай redesign.

Перед правками перечисли:
- какие файлы ожидаешь менять;
- какую проверку повторишь после каждой правки.

Если изменений слишком много, остановись:

Слишком много изменений для одного шага.
Раздели правки на маленькие must-fix задачи.
Код пока не меняй.

Шаг 8. Повтори проверки

После исправлений повтори только релевантные проверки:

• tests/type-check/build/lint, если были затронуты код или сборка;
• manual scenario, если менялся UI;
• export JSON check, если менялись данные;
• SEO/sharing check, если менялись metadata.

Запиши результат в audit report:

### Re-check
- Что исправлено:
- Какие команды прошли:
- Что проверено руками:
- Что осталось в backlog v2: