Proof-of-work evidence bank

1. PROOF_OF_WORK.md собирают, а не выдумывают

Когда дело доходит до резюме и портфолио, почти у всех срабатывает один и тот же инстинкт: открыть чистый файл и написать что-нибудь солидное. «Разрабатывал AI-assisted решения, проектировал workflow, проводил verification». Убедительно. Только чистый файл очень любит фантазию. А карьера любит доказательства.

PROOF_OF_WORK.md нужен именно для того, чтобы сломать этот рефлекс. Не рассказ о том, какой вы перспективный, — индекс доказательств. Каждая запись отвечает на земные вопросы: какую задачу вы решали, что было в вашей зоне ответственности, где помогал Claude Code, чем подтвердили результат, где посмотреть.

Proof-of-work over buzzwords.

Если в вашем файле появляется строка, которая не ведёт ни к одному артефакту, ни к одному diff, ни к одной проверке, — это не proof-of-work. Это уже ближе к жанру «поверьте на слово, было мощно».

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

flowchart LR
    A[Артефакты курса] --> B[PROOF_OF_WORK.md]
    B --> C[Резюме]
    B --> D[GitHub profile]
    B --> E[Интервью-истории]

То есть PROOF_OF_WORK.md — это не финальная витрина, а хорошо собранный склад доказательств. В хорошем смысле склад, конечно, а не тот шкаф, где живут кабели от телефонов 2012 года и зарядка «вдруг пригодится»: туда не тащат всё подряд — только то, что потом легко превратить в публичные карьерные форматы.

2. Карта артефактов: что у вас уже есть

Самая частая ошибка на этом этапе — думать, что такой банк доказательств нужно создавать с нуля. На самом деле основа уже лежит в прошлых проектах и Markdown-файлах курса. Нужно не вдохновение, а инвентаризация: откуда брать материал и что он доказывает.

Вот удобная карта источников:

Здесь есть важный нюанс. Одного capstone мало: он показывает финальный результат и масштаб, а работодателю нужна ещё и механика — маленький bugfix, task spec, review, работа с риском, документирование решений. С другой стороны, и противоположная крайность не лучше: десять маленьких файлов без центрального кейса — россыпь деталей без опорной истории. Хороший банк держит баланс: один сильный якорный проект, а вокруг — несколько эпизодов под конкретные инженерные навыки.

3. Сырой лог, собранный банк и публичная версия

Теперь важный момент, который лучше понять сейчас, а не после случайно опубликованного лога с внутренним URL и половиной чужого контекста. То, что полезно вам и ментору, не обязано в том же виде уходить в GitHub, резюме или рекрутеру. И это нормально.

На практике удобно мыслить тремя слоями:

А вот PROOF_OF_WORK.md — уже не сырьё, но ещё не витрина. Достаточно чистый, чтобы брать фрагменты для профиля, и достаточно подробный, чтобы через месяц не вспоминать мучительно, что именно вы делали в том PR про дубли пагинации.

Поэтому не страшно, если он целиком лежит локально, в приватной папке career/. Страшно другое: когда такого документа нет вообще и вы каждый раз собираете историю по памяти. А память, как известно, умеет быть одновременно очень уверенной и очень неточной.

4. Анатомия одной записи в PROOF_OF_WORK.md

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

Удобный каркас записи может выглядеть так:

## 1. Commerce OS — bugfix дублей в пагинации заказов

**Проблема.** В существующем ecommerce sample codebase pagination иногда возвращала повторяющиеся заказы.

**Что было в моей зоне ответственности.** Я собрал task spec, утвердил scope, проверил diff, добавил regression-проверку и подготовил PR walkthrough.

**Где помогал Claude Code.** Исследование affected files, черновик исправления, подсказки по тестам и summary для PR.

**Проверка.** Regression test, локальный diff review, повторная проверка сценария пагинации.

**Результат.** Баг воспроизводился до фикса и перестал воспроизводиться после него; PR стал reviewable и воспроизводимым.

**Ссылки.** PR, `TASK_SPEC.md`, `REVIEW_NOTES.md`, test file.

**Ограничения.** Работал внутри существующего учебного codebase; не строил всю платформу с нуля.

Обратите внимание на последнюю строку. Она кажется скучной, но именно она спасает от раздувания масштаба. Не «построил ecommerce platform», а «исправил bugfix внутри существующего sample codebase».

Самое ценное место в шаблоне — это пара полей «Что было в моей зоне ответственности» и «Где помогал Claude Code». Их нельзя смешивать. Сольёте в одну кашу — работодателю непонятно, что вы делали лично, а вам потом тяжело отвечать на «Что бы вы объяснили без инструмента?».

Поле «Проверка» тоже не декоративное. Запись без verification выглядит как инженерная сказка. Проверка бывает разной — regression test, smoke check, diff review, demo, reproducibility audit, локальный build, — но её нужно назвать.

И, наконец, «Ограничения». Это очень взрослое поле: оно показывает, что вы понимаете границы собственной работы. Учебный sample repo, demo-ready вместо production-ready, pilot slice вместо полного rollout — всё это отмечаете. На удивление, именно такие честные оговорки делают запись сильнее.

5. Выбор сильных артефактов

После первого прилива энтузиазма почти все делают одно и то же: тащат в банк всё, что коммитили по ходу курса. Получается не банк доказательств, а антресоль с коробками «старые провода, инструкции от роутера и что-то, что жалко выбросить». Сильный банк — наоборот: короткий, разнообразный, легко объяснимый вслух. Выбирайте не «что жалко потерять», а «что именно это доказывает».

Вот простая карта соответствий:

Если говорить совсем практично, то сильный стартовый набор почти всегда строится вокруг трёх-пяти якорей: один показывает основной проект целиком, другой — рабочий эпизод (bugfix или refactor), третий — что вы умеете проектировать сам workflow, а не только исполнять задачи в нём. При широком профиле добавляется артефакт про риск, legacy или migration.

Понять, сильный ли выбранный артефакт, можно очень простым способом. Представьте, что вас разбудили в три часа ночи и попросили за минуту объяснить, что это за файл, какую задачу он решал, как вы проверили результат. Объяснили спокойно, без археологических раскопок в репозитории — артефакт хороший. Сами не понимаете, зачем он нужен, — в публичный банк он тоже не нужен.

6. Sanitization перед публикацией артефактов

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

Перед любым выносом артефакта наружу полезно прогнать его через короткий sanitization-проход:

## Чек-лист санитизации
- [ ] нет API keys, tokens, secrets и реальных `.env` данных
- [ ] нет внутренних URL, staging-адресов и admin-путей
- [ ] нет приватных ticket ID, customer data и чужих имён
- [ ] нет сырых transcript'ов с лишним контекстом
- [ ] нет скопированного проприетарного кода из рабочей среды
- [ ] нет завышенных формулировок про scope и production

Некоторые замены почти всегда полезны:

Хорошее правило здесь очень простое: если после очистки артефакт теряет смысл, не публикуйте его целиком. Оставьте во внутреннем банке с пометкой available on request — либо вынесите в профиль короткое описание с безопасной ссылкой.

И ещё одна мелочь, которую часто недооценивают: screenshots тоже нужно чистить. Внутренний URL, лишняя почта, реальный токен в интерфейсе, приватный комментарий испортят впечатление быстрее слабого кода. Банк доказательств — как уборка перед приходом гостей: стерильности лаборатории никто не требует, но разбрасывать чувствительные вещи по столу не стоит.

7. Первый черновик PROOF_OF_WORK.md

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

Удобно идти по таким шагам:

Ниже — пример совсем первого черновика. Он не обязан быть красивым — обязан быть настоящим.

# PROOF_OF_WORK.md

## 1. Capstone — AI-assisted support inbox
Проблема: нужен demo-ready core flow для обработки типовых support tickets.
Моя ответственность: SPEC.md, scope freeze, diff review, smoke checks, demo.
Роль Claude Code: черновики реализации, test scaffolding, README drafts.
Проверка: 7 smoke/regression checks, reproducibility audit, demo walkthrough.
Ссылки: capstone repo, README, SPEC.md, EVIDENCE.md, demo video.
Ограничения: demo-ready, без production auth и real integrations.

## 2. Commerce OS — bugfix дублей в пагинации заказов
Проблема: pagination возвращала повторяющиеся заказы в существующем sample codebase.
Моя ответственность: task spec, scope, regression check, PR walkthrough.
Роль Claude Code: codebase exploration, черновик фикса, summary для PR.
Проверка: regression test + diff review.
Ссылки: PR, TASK_SPEC.md, REVIEW_NOTES.md.
Ограничения: работал внутри существующего учебного репозитория.

## 3. Workflow Kit — reviewer agent
Проблема: локальный review был непоследовательным и зависел от контекста автора.
Моя ответственность: role design, output contract, boundaries, examples.
Роль Claude Code: черновик инструкции и refinement формулировок.
Проверка: прогон на нескольких diff-сценариях, корректировка findings format.
Ссылки: agents/reviewer.md, REVIEW_CHECKLIST.md.
Ограничения: учебный team workflow artifact, не production rollout.

Обратите внимание на одну полезную деталь: ссылки внутри не обязаны быть публичными URL. Это могут быть путь к файлу, приватный репозиторий, пометка available on request, папка со скриншотами, конкретный PR. Задача не выложить всё в открытый доступ, а перестать собирать профессиональный образ по памяти и собрать его из доказательств.

И это нормально, что ваш первый PROOF_OF_WORK.md может быть неровным, коротким, даже сухим. Один честный файл с тремя сильными записями лучше двадцати красивых формулировок без следов. С ним карьерный запуск перестаёт быть сочинением «почему я молодец» и становится инженерным индексом: вот задача, вот артефакт, вот проверка, вот границы. И из такого файла потом спокойно вырастают NARRATIVE_MAP.md, пункты резюме, profile README и короткие interview stories.