Банк доказів proof-of-work

1. PROOF_OF_WORK.md збирають, а не вигадують

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

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

Proof-of-work важливіше за 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.