# Режим: oferta — Повна оцінка A-F

Коли кандидат вставляє вакансію (текст або URL), ЗАВЖДИ видати 6 блоків:

## Крок 0 — Визначення архетипу

Класифікувати вакансію за одним з архетипів (див. `_shared.md`). Якщо гібрид — вказати 2 найближчих. Це визначає:

- Які proof points пріоритизувати в блоці B
- Як переписати summary в блоці E
- Які історії STAR готувати в блоці F

## Блок A — Резюме ролі

Таблиця з:

- Визначений архетип
- Domain (platform/agentic/LLMOps/ML/enterprise/backend/frontend/devops)
- Function (build/consult/manage/deploy)
- Seniority
- Формат роботи (віддалено/гібрид/офіс)
- Розмір команди (якщо вказано)
- Оформлення (ФОП / КЗпП / ГПД / Дія City — якщо вказано)
- TL;DR в 1 реченні

## Блок B — Збіг з CV

Прочитати `cv.md`. Створити таблицю: кожна вимога JD → точні рядки CV.

**Адаптовано під архетип:**

- Якщо FDE → пріоритизувати proof points швидкої поставки та клієнтської роботи
- Якщо SA → пріоритизувати системний дизайн та інтеграції
- Якщо PM → пріоритизувати product discovery та метрики
- Якщо LLMOps → пріоритизувати evals, observability, pipelines
- Якщо Agentic → пріоритизувати мульти-агент, HITL, оркестрацію
- Якщо Backend → пріоритизувати highload, мікросервіси, масштабування
- Якщо DevOps/SRE → пріоритизувати інфраструктуру, CI/CD, моніторинг

Розділ **прогалин** зі стратегією закриття кожної:

1. Це hard blocker чи nice-to-have?
2. Чи може кандидат продемонструвати суміжний досвід?
3. Чи є портфоліо-проєкт, що закриває цю прогалину?
4. Конкретний план закриття (фраза для супровідного листа, швидкий проєкт тощо)

## Блок C — Рівень і стратегія

1. **Рівень у JD** vs **природний рівень кандидата для цього архетипу**
2. **План "продати senior без обману"**: конкретні фрази, адаптовані під архетип, досягнення для акценту, як позиціонувати досвід
3. **План "якщо знизять рівень"**: прийняти якщо компенсація справедлива, домовитися про перегляд через 6 місяців, чіткі критерії зростання

## Блок D — Компенсація та попит

Використовувати WebSearch для:

- Актуальні зарплати за роллю (DOU.ua/salaries, djinni.co/salaries, Glassdoor, Levels.fyi, Blind)
- Репутація компанії щодо компенсації
- Тренд попиту на роль
- **Валюта**: уточнити USD чи UAH; для ФОП — net чи gross

Таблиця з даними та цитуванням джерел. Якщо даних немає — сказати про це замість вигадування.

**Специфіка України:**

- Зарплати в українському ІТ переважно в **USD** (навіть для ФОП)
- Для ФОП 3-тя група: net ≈ gross × 0.95 (5% єдиний податок) + ЄСВ (~1760 грн/міс)
- Для штатних: net ≈ gross × 0.77 (ПДФО 18% + військовий збір 5%)
- Врахувати бенефіти: медстрахування, навчання, обладнання
- Оформлення: КЗпП/Дія City дають більше гарантій, ніж звичайний ФОП

## Блок E — План персоналізації

| #   | Розділ  | Поточний стан | Пропонована зміна | Чому |
| --- | ------- | ------------- | ----------------- | ---- |
| 1   | Summary | ...           | ...               | ...  |
| ... | ...     | ...           | ...               | ...  |

Топ 5 змін CV + Топ 5 змін у LinkedIn/DOU для максимального збігу.

## Блок F — План співбесід

6-10 історій STAR+R, прив'язаних до вимог JD (STAR + **Рефлексія**):

| #   | Вимога JD | Історія STAR+R | С   | З   | Д   | Р   | Рефлексія |
| --- | --------- | -------------- | --- | --- | --- | --- | --------- |

Стовпець **Рефлексія** фіксує, що було вивчено або що можна було б зробити інакше. Це сигнал сеньйорності — джуніори описують що сталося, сеньйори витягують уроки.

**Банк історій:** Якщо `interview-prep/story-bank.md` існує, перевірити, чи є там ці історії. Якщо ні — додати нові. З часом це формує банк з 5-10 майстер-історій для будь-якого питання на співбесіді.

**Підібрані й обрамлені за архетипом:**

- FDE → акцент на швидкості поставки та клієнтській роботі
- SA → акцент на архітектурних рішеннях
- PM → акцент на discovery та trade-offs
- Backend → акцент на highload, масштабуванні, надійності
- DevOps → акцент на автоматизації, інцидентах, reliability

Включити також:

- 1 рекомендований кейс (який проєкт представити і як)
- Питання-пастки та як на них відповідати (напр.: "Чому пішли з попереднього місця?", "Чому вирішили змінити стек?")

---

## Пост-оцінка

**ЗАВЖДИ** після генерації блоків A-F:

### 1. Зберегти звіт .md

Зберегти повну оцінку в `reports/{###}-{company-slug}-{YYYY-MM-DD}.md`.

- `{###}` = наступний порядковий номер (3 цифри, zero-padded). Щоб виділити цей номер атомарно та уникнути станів гонки, ви ПОВИННІ виконати `node reserve-report-num.mjs` для резервування номера (stdout поверне `{###}`), записати звіт, а потім виконати `node reserve-report-num.mjs --release {###}` для звільнення маркера (sentinel).
- `{company-slug}` = назва компанії: lowercase, пробіли замінити на `-`, прибрати спецсимволи (наприклад, `Acme Corp` → `acme-corp`)
- `{YYYY-MM-DD}` = поточна дата

**Формат звіту:**

```markdown
# Оцінка: {Компанія} — {Роль}

**Дата:** {YYYY-MM-DD}
**Архетип:** {визначений}
**Бал:** {X/5}
**Легітимність:** {tier}
**URL:** {посилання на вакансію}
**PDF:** {шлях або "очікується"}

---

## A) Резюме ролі

(повний вміст блоку A)

## B) Збіг з CV

(повний вміст блоку B)

## C) Рівень і стратегія

(повний вміст блоку C)

## D) Компенсація та попит

(повний вміст блоку D)

## E) План персоналізації

(повний вміст блоку E)

## F) План співбесід

(повний вміст блоку F)

## G) Чернетки відповідей на форму

(тільки якщо бал >= 4.5 — чернетки відповідей для форми відгуку)

---

## Витягнуті ключові слова

(список з 15-20 keywords з JD для ATS-оптимізації)
```

### 2. Зареєструвати в трекері

Для **нового** запису не редагувати `data/applications.md` напряму. Замість цього записати один TSV-рядок у `batch/tracker-additions/{num}-{company-slug}.tsv` з 8 або 9 колонками через табуляцію:

```
{num}\t{date}\t{company}\t{role}\t{status}\t{score}\t{pdf_emoji}\t[{num}](reports/{num}-{slug}-{date}.md)\t{note}
```

- `{num}` = наступний порядковий номер (ціле число, обчислити з `reports/`)
- `{status}` = `Evaluated`
- `{score}` = формат `X.X/5` (наприклад, `4.2/5`)
- `{pdf_emoji}` = `✅` або `❌`
- `{note}` = короткий коментар (опціонально, колонку можна опустити)

Потім виконати `node merge-tracker.mjs` для злиття в `data/applications.md`.

Для **існуючого** запису допустиме пряме оновлення в `data/applications.md` (статус, PDF, посилання на звіт).